From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61371 invoked by alias); 10 Feb 2016 11:37:09 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 61356 invoked by uid 89); 10 Feb 2016 11:37:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-93.9 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=cygwin-ug-net, cygwinugnet, UD:ntsec.html, ntsec.html X-HELO: calimero.vinschen.de Received: from ipbcc0d020.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Feb 2016 11:37:08 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 924D6A80586; Wed, 10 Feb 2016 12:37:05 +0100 (CET) Date: Wed, 10 Feb 2016 11:37:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: chmod failed: Invalid argument Message-ID: <20160210113705.GA15391@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20160128144429.GC27369@calimero.vinschen.de> <20160128172256.GB18626@calimero.vinschen.de> <20160128204021.GA7055@calimero.vinschen.de> <56AE6D83.9070201@gmx.de> <20160208142930.GF12975@calimero.vinschen.de> <56BB1813.9050102@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <56BB1813.9050102@gmx.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-02/txt/msg00133.txt.bz2 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3926 On Feb 10 11:59, Rainer Blome wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 08.02.2016 15:29, Corinna Vinschen wrote: > > On Jan 31 21:24, Rainer Blome wrote: > >> On 28.01.2016 21:40, Corinna Vinschen wrote: > >>>>> On a hunch, do you have old /etc/passwd and /etc/group > >>>>> files > >>>> There is no `/etc/group`, but `/etc/passwd` defines the > >>>> group ID of my user as 513 > >> On a Cygwin 2.3.1 on a different machine, `/etc/passwd` also has=20 > >> 513 in the group column of all users. Yet, when I ask for `id`, > >> I get something like this (translated): > >>=20 > >> uid=3D197609(username) gid=3D197121(None) \=20 > >> Groups=3D197121(None),545(Users),... > >=20 > > These values make sense. >=20 > Please enlighten me. To me it looks as if cygwin or at least mkpasswd > formerly used 513 as the gid for "None", and switched to 197121 at > some point. Keep in mind that uid and gid values are POSIX concepts, not Windows concepts. Windows uses a SID. Cygwin translates SIDs into uids and gids using either the preferred computation directly from SAM or AD, or the uid/gid values mentioned in /etc/passwd and /etc/group. What it uses depends on the content of /etc/nsswitch.conf, and if the /etc/passwd and /etc/group files exist or not. See the User's Guide at https://cygwin.com/cygwin-ug-net/ntsec.html for all the gory details. 513 was the gid value for "None" when fetched from /etc/group. 197121 is the computed gid value for the group "None", using the algorithm explained in https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how: "None" is a local SAM account with RID 513, therefore its computed gid value is 0x30000 + 513 =3D 197121. > I currently do not understand this: >=20 > Before I changed gid of my user from 513 to 197121 in /etc/passwd, ls > printed 513 as the group of files in the home directory. After the > change, ls prints "None" as the group. 513 was probably missing from /etc/group, but it was mentioned in /etc/passwd. The ambiguity is the problem, but off the top of my head I can't reproduce how Cygwin struggles to resolve it. Not very well, apparently. > But 197121 is the id of None. > At first sight, this looks like the file group ownership has changed > from 513 to 197121, Of course not. The actual entry in the file's DACL contains the SID of the group "None". Everything else is just a mapping to the POSIX concept of uids and gids. Think of Cygwin's uid and gids as just a virtual representation of the reality. Either computed directly from the SID, or taken from /etc/passwd and /etc/group if they exist and are active per /etc/nsswitch.conf. > but I do not see why that should have happened. > >> No doubt. So what kind of maintenance do these files need? Should > >> I have known that they do? > >=20 > > They should match. For instance, one problem is if your passwd=20 > > entry contains a gid not available in either the Windows user DB > > or /etc/group. >=20 > Does this mean that if /etc/passwd exists, /etc/group must also exist > (and match)? Or that, if /etc/passwd gives a currently-non-canonical > gid such as 513, /etc/group must exist and define that gid? The latter in the first place. Ideally you don't use the files at all and let Cygwin compute the uid/gid values. If you feel more comfortable with, say, changing your home dir using an /etc/passwd entry, rather than one of the other methods described in https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch you just generate a single passwd entry for your user: $ mkpasswd -c > /etc/passwd Then change home dir or shell, but keep the rest of the line intact, *especially* the uid and gid values since they will match the computed values and not lead to ambiguity. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWuyDhAAoJEPU2Bp2uRE+ggOEP/37LhwLL+wByBNI/IGTs3OEl PkW6zPfksIVfcxjySSgqiZFHqlvZEhwBlm6oFXNbwAi6ykSdk0WjzsEvnZelm1Az 7lppNK++R0s8zWtHqyhOyHNlge8sZxuc19C4YGyRTq+hCenNTbIiULokkmlibilY CpaRqwlrKUiKTtbBoaI068MP/IG5+ofNy8Bg63tPWac/lrKRT0L2LfX3BrauoOD6 4cXezF1+5p/XA9703nHRvkSIcLEkE/YOC6JAsaKreeXtDl5quJnu8FXrXJIP86L0 IVnAICzhUqoTF59vxEP6DINZ2E+eFWQpaocMqjiUFlxJATkXU5z3p+PXs7tOShGT DZPubY4a1VGtYiG0cxO7+rgMG7jzt8cfsKNTRqpoSFzW2x23kCr0R5IjO0x9W54w Ie095vZYGViFbCLEPB6uFxatqO26XUeB+CBWeqLNokzcsOxLdM+3mmcnsDYeA/GF b80EM070m2FYA8PwCrFlFKKtDtI//KjCbRBdrkRy80pvhZZ+TVtrhgA2u/LPcc8W LCODfTD74U9UFn8HRyBG0OrCcWVfpibOeo+jxTJuT1FH+Y702HhJurP0GYgrgAS+ +fX4Yo8yvf9hJoGHrHfE/Do1UOGWPr9v5PWkoMCdxbNZkrLtHn0MEBG5P9WD0Jih lJ/xnNOSO+63gSA4kS90 =kUEU -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--