Re: chmod failed: Invalid argument

Re: chmod failed: Invalid argument

[Rainer Blome]

(Apologies for not using the reply feature, I was not
subscribed when the last mail was sent. I am now subscribed.)

> Corinna Vinschen wrote:
> On Jan 28 01:27, Christopher Cobb wrote:
>> Or maybe chmod is broken, like it is on my machine:
>> $ chmod 777 x
>> chmod: changing permissions of âxâ: Invalid argument

> Can you please send the icacls output of the current directory and
> the icacls out for the file x?

Here are the icacls outputs for the test case:

$ umask
0027

$ mkdir bar
$ cd bar
$ icacls .
. hostname\username:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

$ touch foo
$ ls -la
total 0
drwx------+ 1 username 213 0 Jan 28 15:14 .
drwx------+ 1 username 213 0 Jan 28 15:14 ..
-rwx------  1 username 213 0 Jan 28 15:14 foo

$ icacls foo
foo hostname\username:(I)(F)

Successfully processed 1 files; Failed processing 0 files

$ icacls .
. hostname\username:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: chmod failed: Invalid argument

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

On Jan 28 15:24, Rainer Blome wrote:
> (Apologies for not using the reply feature, I was not
> subscribed when the last mail was sent. I am now subscribed.)

The "In-Reply-To" is still missing in your mails, so you're invariably
breaking threading.  T'would be nice if you could make your mailer
behave :)

> > Corinna Vinschen wrote:
> > On Jan 28 01:27, Christopher Cobb wrote:
> >> Or maybe chmod is broken, like it is on my machine:
> >> $ chmod 777 x
> >> chmod: changing permissions of âxâ: Invalid argument
> 
> > Can you please send the icacls output of the current directory and
> > the icacls out for the file x?
> 
> Here are the icacls outputs for the test case:
> 
> $ umask
> 0027
> 
> $ mkdir bar
> $ cd bar
> $ icacls .
> . hostname\username:(I)(OI)(CI)(F)

This... doesn't look like an ACL created by Cygwin.  If you're running
Cygwin 2.4.1, the acl should always at least contain ACEs for the
default POSIX perms, plus a NULL ACE:

foo NULL SID:(DENY)(Rc,S)
    VINSCHEN\corinna:(R,W,D,WDAC,WO)
    VINSCHEN\vinschen:(R)
    Everyone:(Rc,S,RA)

For directories also inheritable default perms for "CREATOR OWNER" and
"CREATOR GROUP".  Is that really a Cygwin mkdir?!?  And then, what about
this unknwon group with gid 213?  What does

  $ getent group 213

print?  Something's weird here...


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Aw: Re: chmod failed: Invalid argument

[Rainer Blome]

> Corinna Vinschen wrote 2016-01-28 15-44:
> On Jan 28 15:24, Rainer Blome wrote:
>
> The "In-Reply-To" is still missing in your mails, so you're invariably
> breaking threading.  T'would be nice if you could make your mailer
> behave :)

This is the first time that I have a mail to reply to,
hope the threading is preserved now.
 
> > > Corinna Vinschen wrote:
> > > On Jan 28 01:27, Christopher Cobb wrote:
> > >> Or maybe chmod is broken, like it is on my machine:
> > >> $ chmod 777 x
> > >> chmod: changing permissions of âxâ: Invalid argument
> > 
> > > Can you please send the icacls output of the current directory and
> > > the icacls out for the file x?
> > 
> > Here are the icacls outputs for the test case:
> > 
> > $ umask
> > 0027
> > 
> > $ mkdir bar
> > $ cd bar
> > $ icacls .
> > . hostname\username:(I)(OI)(CI)(F)
> 
> This... doesn't look like an ACL created by Cygwin.

----
$ type mkdir
mkdir is hashed (/usr/bin/mkdir)
$ md5sum /usr/bin/mkdir
25471314acd68f352523ba17eafbb7f9 */usr/bin/mkdir
----

> If you're running Cygwin 2.4.1,

CYGWIN_NT-6.1 hostname 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin

> the acl should always at least contain ACEs for the
> default POSIX perms, plus a NULL ACE:
> 
> foo NULL SID:(DENY)(Rc,S)
>     VINSCHEN\corinna:(R,W,D,WDAC,WO)
>     VINSCHEN\vinschen:(R)
>     Everyone:(Rc,S,RA)

In Windows Explorer -> `bar` -> RMB -> Properties -> Security ->
Advanced, I am told that it inherits ist permissions from `base`,
the parent of `bar`. (To be precise, it inherits from its
grandparent, but I assume that the length of the ancestor chain is
not important here.)

> For directories also inheritable default perms for "CREATOR OWNER" and
> "CREATOR GROUP".  Is that really a Cygwin mkdir?!?

As far as can see, yes, see above.

> And then, what about
> this unknwon group with gid 213?  What does
> 
>   $ getent group 213
> 
> print?  Something's weird here...

getent group 213; echo $?
2

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Re: chmod failed: Invalid argument

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

On Jan 28 17:06, Rainer Blome wrote:
> > Corinna Vinschen wrote 2016-01-28 15-44:
> > On Jan 28 15:24, Rainer Blome wrote:
> >
> > The "In-Reply-To" is still missing in your mails, so you're invariably
> > breaking threading.  T'would be nice if you could make your mailer
> > behave :)
> 
> This is the first time that I have a mail to reply to,
> hope the threading is preserved now.

Yes it is, thanks a lot!

> > the acl should always at least contain ACEs for the
> > default POSIX perms, plus a NULL ACE:
> > 
> > foo NULL SID:(DENY)(Rc,S)
> >     VINSCHEN\corinna:(R,W,D,WDAC,WO)
> >     VINSCHEN\vinschen:(R)
> >     Everyone:(Rc,S,RA)
> 
> In Windows Explorer -> `bar` -> RMB -> Properties -> Security ->
> Advanced, I am told that it inherits ist permissions from `base`,
> the parent of `bar`. (To be precise, it inherits from its
> grandparent, but I assume that the length of the ancestor chain is
> not important here.)

This means the permission have been inherited when creating the
file but Cygwin couldn't overwrite the ACL with a POSIXified variant
for one reason or another.  It might have to do with this mysterious
group 213...

> > For directories also inheritable default perms for "CREATOR OWNER" and
> > "CREATOR GROUP".  Is that really a Cygwin mkdir?!?
> 
> As far as can see, yes, see above.
> 
> > And then, what about
> > this unknwon group with gid 213?  What does
> > 
> >   $ getent group 213
> > 
> > print?  Something's weird here...
> 
> getent group 213; echo $?
> 2

Ok, that's not exactly helpful to analyze this problem.  Can you try
running another strace

  strace -o getfacl.trace getfacl <file>

on a file which has supposedly that group as owning group, e.g.  your
"base" dir?  We might have a chance to look at the SID of group 213 in
there.

On a hunch, do you have old /etc/passwd and /etc/group files by any
chance?  Does moving them out of /etc (don't delete them for now!),
exiting from Cygwin and starting a new shell somehow fix things for you?
How do the files look like?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: chmod failed: Invalid argument

[Rainer Blome]

> Corinna Vinschen wrote 2016-01-28 18:22:
> On Jan 28 17:06, Rainer Blome wrote:
> > > Corinna Vinschen wrote 2016-01-28 15-44:
> > > On Jan 28 15:24, Rainer Blome wrote:
> > > the acl should always at least contain ACEs for the
> > > default POSIX perms, plus a NULL ACE:
> > > 
> > > foo NULL SID:(DENY)(Rc,S)
> > >     VINSCHEN\corinna:(R,W,D,WDAC,WO)
> > >     VINSCHEN\vinschen:(R)
> > >     Everyone:(Rc,S,RA)
> > 
> > In Windows Explorer -> `bar` -> RMB -> Properties -> Security ->
> > Advanced, I am told that it inherits ist permissions from `base`,
> > the parent of `bar`. (To be precise, it inherits from its
> > grandparent, but I assume that the length of the ancestor chain is
> > not important here.)
> 
> This means the permission have been inherited when creating the
> file but Cygwin couldn't overwrite the ACL with a POSIXified variant
> for one reason or another.  It might have to do with this mysterious
> group 213...
> 
> > > For directories also inheritable default perms for "CREATOR OWNER" and
> > > "CREATOR GROUP".  Is that really a Cygwin mkdir?!?
> > 
> > As far as can see, yes, see above.
> > 
> > > And then, what about
> > > this unknwon group with gid 213?  What does
> > > 
> > >   $ getent group 213
> > > 
> > > print?  Something's weird here...
> > 
> > getent group 213; echo $?
> > 2
> 
> Ok, that's not exactly helpful to analyze this problem.  Can you try
> running another strace
> 
>   strace -o getfacl.trace getfacl <file>
> 
> on a file which has supposedly that group as owning group, e.g.  your
> "base" dir?  We might have a chance to look at the SID of group 213 in
> there.

That command segfaults, just as `strace : ` does.

> On a hunch, do you have old /etc/passwd and /etc/group files by any
> chance?  Does moving them out of /etc (don't delete them for now!),
> exiting from Cygwin and starting a new shell somehow fix things for you?
> How do the files look like?

Define "old"! ;-) Yes, I do. There is no `/etc/group`, but
`/etc/passwd` defines the group ID of my user as 213 (the real ID
is a bit different, to be honest, but I do not think that matters.)
When I rename the file and open a new Cygwin terminal, things start
to work. `strace echo` yields the expected output, `chmod` does
what it's supposed to do, and `git config`, `git init` and `git
clone foo foo2` work as well.

The `git clone repo:bar` then fails because my `~/.ssh` is
apparently no longer found (and I can only log in via SSH
key). This is a bit surprising, because in the new terminal,
`$HOME` and `~/.` are still set the way I specified it in the old
`/etc/passwd` (now with extension `.renamed`). So some programs
apparently use one method of determining the home directory, and
others use a different method. I will look into that tomorrow.

If, after this "breakthrough", there is still value in looking
further into the ACLs, I am willing to do that. However, the strace
output looks awfully laborious to sanitize, so I can not do this
today.

Thanks for the help so far.

Rainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: chmod failed: Invalid argument

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4609 bytes --]

On Jan 28 19:43, Rainer Blome wrote:
> > Corinna Vinschen wrote 2016-01-28 18:22:
> > On Jan 28 17:06, Rainer Blome wrote:
> > > > Corinna Vinschen wrote 2016-01-28 15-44:
> > > > On Jan 28 15:24, Rainer Blome wrote:
> > > > the acl should always at least contain ACEs for the
> > > > default POSIX perms, plus a NULL ACE:
> > > > 
> > > > foo NULL SID:(DENY)(Rc,S)
> > > >     VINSCHEN\corinna:(R,W,D,WDAC,WO)
> > > >     VINSCHEN\vinschen:(R)
> > > >     Everyone:(Rc,S,RA)
> > > 
> > > In Windows Explorer -> `bar` -> RMB -> Properties -> Security ->
> > > Advanced, I am told that it inherits ist permissions from `base`,
> > > the parent of `bar`. (To be precise, it inherits from its
> > > grandparent, but I assume that the length of the ancestor chain is
> > > not important here.)
> > 
> > This means the permission have been inherited when creating the
> > file but Cygwin couldn't overwrite the ACL with a POSIXified variant
> > for one reason or another.  It might have to do with this mysterious
> > group 213...
> > 
> > > > For directories also inheritable default perms for "CREATOR OWNER" and
> > > > "CREATOR GROUP".  Is that really a Cygwin mkdir?!?
> > > 
> > > As far as can see, yes, see above.
> > > 
> > > > And then, what about
> > > > this unknwon group with gid 213?  What does
> > > > 
> > > >   $ getent group 213
> > > > 
> > > > print?  Something's weird here...
> > > 
> > > getent group 213; echo $?
> > > 2
> > 
> > Ok, that's not exactly helpful to analyze this problem.  Can you try
> > running another strace
> > 
> >   strace -o getfacl.trace getfacl <file>
> > 
> > on a file which has supposedly that group as owning group, e.g.  your
> > "base" dir?  We might have a chance to look at the SID of group 213 in
> > there.
> 
> That command segfaults, just as `strace : ` does.
> 
> > On a hunch, do you have old /etc/passwd and /etc/group files by any
> > chance?  Does moving them out of /etc (don't delete them for now!),
> > exiting from Cygwin and starting a new shell somehow fix things for you?
> > How do the files look like?
> 
> Define "old"! ;-) Yes, I do. There is no `/etc/group`, but
> `/etc/passwd` defines the group ID of my user as 213 (the real ID
> is a bit different, to be honest, but I do not think that matters.)

Ouch, that may be the reason.  I have to check that but your passwd
and group files are

1) Not required anymore, see https://cygwin.com/cygwin-ug-net/ntsec.htm,
   and

2) *iff* they are there, there's good reason to have them in a good
   working shape.

> When I rename the file and open a new Cygwin terminal, things start
> to work. `strace echo` yields the expected output, `chmod` does
> what it's supposed to do, and `git config`, `git init` and `git
> clone foo foo2` work as well.
> 
> The `git clone repo:bar` then fails because my `~/.ssh` is
> apparently no longer found (and I can only log in via SSH
> key). This is a bit surprising, because in the new terminal,
> `$HOME` and `~/.` are still set the way I specified it in the old
> `/etc/passwd` (now with extension `.renamed`).  So some programs
> apparently use one method of determining the home directory, and
> others use a different method. I will look into that tomorrow.

Yes, indeed.  Ssh ignores $HOME and it does so as long as it exists.
Ssh uses the pw_dir field from your passwd entry and that in turn is
determined by /etc/passwd if it exists, or by /etc/nsswitch.conf. 
See the extensive documentation starting at
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
The default homedir is /home/<USERNAME>.  There are a few knobs to
play with to change this setting, see
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-home

> If, after this "breakthrough", there is still value in looking
> further into the ACLs, I am willing to do that. However, the strace
> output looks awfully laborious to sanitize, so I can not do this
> today.

There's not much to sanitize usually, a few env variables you don't like
to publish, that's all.  Other than that, it might not be required
anymore to generate the strace at all.  Writing this mail is my last
action for today aswell, at least :)

> Thanks for the help so far.

Thanks for *your* help.  I expect there are still a few problems in that
code since not even a multi-month testphase finds all problems.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: chmod failed: Invalid argument

[Rainer Blome]

On 28.01.2016 21:40, Corinna Vinschen wrote:
> On Jan 28 19:43, Rainer Blome wrote:
>>> Corinna Vinschen wrote 2016-01-28 18:22:
>>>> On Jan 28 17:06, Rainer Blome wrote:
>>>>> Corinna Vinschen wrote 2016-01-28 15-44: And then, what about
>>>>> this unknwon group with gid 213?  What does
>>>>> 
>>>>> $ getent group 213
>>>>> 
>>>>> print?  Something's weird here...
>>>> 
>>>> getent group 213; echo $? # getent prints nothing, returns 2
>>>> 
>>> On a hunch, do you have old /etc/passwd and /etc/group files by
>>> any chance?  Does moving them out of /etc (don't delete them for
>>> now!), exiting from Cygwin and starting a new shell somehow fix
>>> things for you? How do the files look like?
>> 
>> Define "old"! ;-) Yes, I do. There is no `/etc/group`, but 
>> `/etc/passwd` defines the group ID of my user as 213 (the real ID
>> is a bit different, to be honest, but I do not think that 
>> matters.)

The real group ID is 513, by the way. On a Cygwin 2.3.1 on a different
machine, `/etc/passwd` also has 513 in the group column of all users.
Yet, when I ask for `id`, I get something like this (translated):

 uid=197609(username) gid=197121(None) \
  Groups=197121(None),545(Users),...

> Ouch, that may be the reason.  I have to check that but your passwd
> and group files are
> 
> 1) Not required anymore, see 
> https://cygwin.com/cygwin-ug-net/ntsec.htm, and

Well, I do not use Active Directory, and I try to maintain a stable
home directory across new machines, drives or Windows reinstalls,
so I specify this directory in `/etc/passwd`. Since it is small,
I see no harm in using this method.

On my Cygwin 2.4.1, to get things to run the way I want them, I
renamed `/etc/passwd.renamed` back to `/etc/passwd`, and replaced
the old group id by the ID of group "None", 197121.
In a new terminal, things now run as expected, SSH finds its .ssh
directory and `chmod` etc. work the way that they should.

> 2) *iff* they are there, there's good reason to have them in a good
> working shape.

No doubt. So what kind of maintenance do these files need?
Should I have known that they do?

>> The `git clone repo:bar` then fails because my `~/.ssh` is 
>> apparently no longer found (and I can only log in via SSH key). 
>> This is a bit surprising, because in the new terminal, `$HOME` and
>> `~/.` are still set the way I specified it in the old `/etc/passwd`
>> (now with extension `.renamed`).  So some programs apparently use
>> one method of determining the home directory, and others use a
>> different method. I will look into that tomorrow.
> 
> Yes, indeed.  Ssh ignores $HOME and it does so as long as it exists.
> Ssh uses the pw_dir field from your passwd entry and that in turn is
> determined by /etc/passwd if it exists, or by /etc/nsswitch.conf. See
> the extensive documentation starting at 
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch 
> The default homedir is /home/<USERNAME>.  There are a few knobs to 
> play with to change this setting, see 
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-home

In the User-specific Windows environment variables, `$HOME` was
set, so that most programs still saw that. To simplify, I removed
that setting, hoping I did not use it in some Windows batch file. :-)

>> If, after this "breakthrough", there is still value in looking 
>> further into the ACLs, I am willing to do that.
> it might not be required anymore to generate the strace at all.

Then I'll skip that for now. Maybe a bogus group setting in
`/etc/passwd` is enough to reproduce the issue.

>> Thanks for the help so far.
> 
> Thanks for *your* help.  I expect there are still a few problems in
> that code since not even a multi-month testphase finds all problems.

I am curious what change triggered the issue, can you point me to a
commit or change-log entry?

Rainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: chmod failed: Invalid argument

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

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 by
> >>> any chance?  Does moving them out of /etc (don't delete them for
> >>> now!), exiting from Cygwin and starting a new shell somehow fix
> >>> things for you? How do the files look like?
> >> 
> >> Define "old"! ;-) Yes, I do. There is no `/etc/group`, but 
> >> `/etc/passwd` defines the group ID of my user as 213 (the real ID
> >> is a bit different, to be honest, but I do not think that 
> >> matters.)
> 
> The real group ID is 513, by the way. On a Cygwin 2.3.1 on a different
> machine, `/etc/passwd` also has 513 in the group column of all users.
> Yet, when I ask for `id`, I get something like this (translated):
> 
>  uid=197609(username) gid=197121(None) \
>   Groups=197121(None),545(Users),...

These values make sense.

> > Ouch, that may be the reason.  I have to check that but your passwd
> > and group files are
> > 
> > 1) Not required anymore, see 
> > https://cygwin.com/cygwin-ug-net/ntsec.htm, and
> 
> Well, I do not use Active Directory, and I try to maintain a stable
> home directory across new machines, drives or Windows reinstalls,
> so I specify this directory in `/etc/passwd`. Since it is small,
> I see no harm in using this method.
> 
> On my Cygwin 2.4.1, to get things to run the way I want them, I
> renamed `/etc/passwd.renamed` back to `/etc/passwd`, and replaced
> the old group id by the ID of group "None", 197121.
> In a new terminal, things now run as expected, SSH finds its .ssh
> directory and `chmod` etc. work the way that they should.
> 
> > 2) *iff* they are there, there's good reason to have them in a good
> > working shape.
> 
> No doubt. So what kind of maintenance do these files need?
> Should I have known that they do?

They should match.  For instance, one problem is if your passwd entry
contains a gid not available in either the Windows user DB or /etc/group.

> > Thanks for *your* help.  I expect there are still a few problems in
> > that code since not even a multi-month testphase finds all problems.
> 
> I am curious what change triggered the issue, can you point me to a
> commit or change-log entry?

Not a single one.  It's probably related to the new ACL handling but
knowing it more specificially requires debugging.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: chmod failed: Invalid argument

[Rainer Blome]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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 
>> 513 in the group column of all users. Yet, when I ask for `id`,
>> I get something like this (translated):
>> 
>> uid=197609(username) gid=197121(None) \ 
>> Groups=197121(None),545(Users),...
> 
> These values make sense.

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.

I currently do not understand this:

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. But 197121 is the id of None.
At first sight, this looks like the file group ownership has changed
from 513 to 197121, 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?
> 
> They should match.  For instance, one problem is if your passwd 
> entry contains a gid not available in either the Windows user DB
> or /etc/group.

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?

Regards, Rainer
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWuxgTAAoJEI/iM7d3pEsvXnEQAMv8VT5Frv9uvVt7kMuu1SA/
G5K0AnuzS3XCZIZzVgOHls+6XrbOLXVLi6BCf7i2bFm9tBhsT7/U+X4/hfMTMUuz
OsefO6EHmGr+c8jEzm9y2OpU10zf+rsOqgFMD7qnUoJ2kbpUNY+dGKnUOYsQmnZ/
gdUlufQTpAoMsNiEsTlseaiXdGiSS6pCNu7W0HrIn7TI8uPCAxA7zqi5S53a3zpQ
4x7E4+0QS3KxLT5C20RWRhGEx/+efUAWH/G/UJNEdZJ+hc5eG4Abz4Bh7wx0ITuJ
FabuktphYS1RuRxEPJgNpLdUtCervWzNe223aHdcHR+lJygPCcKHBII6h1kU6tiK
vjpvG5wyDvWFewBoAqD3uWwYwo+tMaRMj3rSMXApRcO5IHDgid54Bi7ETwxurfO0
0cMHKuRNsGTO1BZXfZJZBChKRkDDYoF165TvMMMYTop2hUwcGJVl06s48dRnNfc9
h5tgqB3IKBgDb2I1D6GK/yjkMNIH5x9J9Z51qXKFhWs2erosndLy2K0MUk8i23Je
YqYbucBZ+6ynoRKUfUzjtJNL062ZxfBoQHpPJ9PJHJQluagFdkkeBsbxZhdrtYnj
6PNWqTTYWGm+V8Un+LwSqEr1rPDcMtPBkWTxSnjdnBL3iSd85FgXaVrcM+Lc2ptp
Ud3/WslWQqlC69NdFiRK
=kX/M
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: chmod failed: Invalid argument

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

On Feb 10 11:59, Rainer Blome wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 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 
> >> 513 in the group column of all users. Yet, when I ask for `id`,
> >> I get something like this (translated):
> >> 
> >> uid=197609(username) gid=197121(None) \ 
> >> Groups=197121(None),545(Users),...
> > 
> > These values make sense.
> 
> 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 = 197121.

> I currently do not understand this:
> 
> 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?
> > 
> > They should match.  For instance, one problem is if your passwd 
> > entry contains a gid not available in either the Windows user DB
> > or /etc/group.
> 
> 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]