chmod g+ws unsuccessful, "NULL SID" icacls missing

chmod g+ws unsuccessful, "NULL SID" icacls missing

[Norton Allen]

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

I briefly raised this issue months ago and am trying to resolve it again 
now.

What I am trying to do is setup permissions so multiple users on one 
machine can share full control over a particular directory hierarchy.

On Linux I have usually been able to make things work with:

    $ mkdir shared_dir
    $ chgrp shared_group shared_dir
    $ chmod g+ws shared_dir
    $ umask 2

User shells are configured with umask 2 so files they create have group 
write. Users belong to shared_group. Files and subdirs created under 
shared_dir are all in group shared_group. Files moved in retain their 
original group, but the group members still have permission to rename or 
delete them.

The problem:

$ chmod g+ws fails to set the 's' bit, and the resulting icacls output 
does not contain any "NULL SID" entries. I am seeing the same problem on 
(at least) two different systems setup by my organization. One of these 
was just re-imaged and I installed Cygwin yesterday with no customized 
configurations. AV is Windows Defender, but I suspect if that were the 
culprit, there would have been more noise.

I suspect there might be a group policy or something that is interfering 
with Cygwin's strategy for implementing POSIX permissions. I am pretty 
sure this worked correctly at some point in the past.

Has anyone encountered this?

Does group policy seem like a likely suspect? Anyone know which 
policy(ies)? I think I might be able to get IT to cut me slack if I knew 
what to ask for.

I have also played with using setfacl directly to add permissions, but 
as anyone who has read about Cygwin file permissions might guess, that 
tends to have mixed/poor results, but I'd be open to any suggestions.

Re: chmod g+ws unsuccessful, "NULL SID" icacls missing

[Norton Allen]

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

On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
> I briefly raised this issue months ago and am trying to resolve it 
> again now.
>
> What I am trying to do is setup permissions so multiple users on one 
> machine can share full control over a particular directory hierarchy.
>
> On Linux I have usually been able to make things work with:
>
>    $ mkdir shared_dir
>    $ chgrp shared_group shared_dir
>    $ chmod g+ws shared_dir
>    $ umask 2
>
> User shells are configured with umask 2 so files they create have 
> group write. Users belong to shared_group. Files and subdirs created 
> under shared_dir are all in group shared_group. Files moved in retain 
> their original group, but the group members still have permission to 
> rename or delete them.
>
> The problem:
>
> $ chmod g+ws fails to set the 's' bit, and the resulting icacls output 
> does not contain any "NULL SID" entries. I am seeing the same problem 
> on (at least) two different systems setup by my organization. One of 
> these was just re-imaged and I installed Cygwin yesterday with no 
> customized configurations. AV is Windows Defender, but I suspect if 
> that were the culprit, there would have been more noise.
>
> I suspect there might be a group policy or something that is 
> interfering with Cygwin's strategy for implementing POSIX permissions. 
> I am pretty sure this worked correctly at some point in the past.
>
> Has anyone encountered this?
>
> Does group policy seem like a likely suspect? Anyone know which 
> policy(ies)? I think I might be able to get IT to cut me slack if I 
> knew what to ask for.
>
> I have also played with using setfacl directly to add permissions, but 
> as anyone who has read about Cygwin file permissions might guess, that 
> tends to have mixed/poor results, but I'd be open to any suggestions.
>

I don't actually have a system on which this is working to compare to, 
so I am not exactly sure how it is supposed to look when it's working 
correctly. The current behavior on  my new uncustomized installation:

    $ cd /home
    $ mkdir foo
    $ ls -ld foo
    drwxr-xr-x 1 nort None 0 Feb  9 12:20 foo

    $ chgrp testflight foo
    $ ls -ld foo
    drwxr-xr-x 1 nort testflight 0 Feb  9 12:20 foo

    $ chmod g+w foo
    $ ls -ld foo
    drwxrwxr-x 1 nort testflight 0 Feb  9 12:21 foo

    $ chmod g+s foo
    $ ls -ld foo
    drwxrwxr-x 1 nort testflight 0 Feb  9 12:21 foo

Comparing getfacl and icacls output between the last two steps indicates 
that chmod g+s foo does exactly nothing. I ran strace on that and see 
that the chmod() call returns zero, but I don't know what's going inside 
that.

Any idea what g+s should be doing? Any more/better information I can 
provide?

Re: chmod g+ws unsuccessful, "NULL SID" icacls missing

[Corinna Vinschen]

Hi Norton,

On Feb  9 13:25, Norton Allen via Cygwin wrote:
> On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
> > I briefly raised this issue months ago and am trying to resolve it again
> > now.
> > 
> > What I am trying to do is setup permissions so multiple users on one
> > machine can share full control over a particular directory hierarchy.
> > 
> > On Linux I have usually been able to make things work with:
> > 
> >    $ mkdir shared_dir
> >    $ chgrp shared_group shared_dir
> >    $ chmod g+ws shared_dir
> >    $ umask 2
> > 
> > User shells are configured with umask 2 so files they create have group
> > write. Users belong to shared_group. Files and subdirs created under
> > shared_dir are all in group shared_group. Files moved in retain their
> > original group, but the group members still have permission to rename or
> > delete them.
> > 
> > The problem:
> > 
> > $ chmod g+ws fails to set the 's' bit, and the resulting icacls output
> > does not contain any "NULL SID" entries. I am seeing the same problem on
> > (at least) two different systems setup by my organization. One of these
> > was just re-imaged and I installed Cygwin yesterday with no customized
> > configurations. AV is Windows Defender, but I suspect if that were the
> > culprit, there would have been more noise.
> > 
> > I suspect there might be a group policy or something that is interfering
> > with Cygwin's strategy for implementing POSIX permissions. I am pretty
> > sure this worked correctly at some point in the past.
> > 
> > Has anyone encountered this?
> > 
> > Does group policy seem like a likely suspect? Anyone know which
> > policy(ies)? I think I might be able to get IT to cut me slack if I knew
> > what to ask for.
> > 
> > I have also played with using setfacl directly to add permissions, but
> > as anyone who has read about Cygwin file permissions might guess, that
> > tends to have mixed/poor results, but I'd be open to any suggestions.
> > 
> 
> I don't actually have a system on which this is working to compare to, so I
> am not exactly sure how it is supposed to look when it's working correctly.
> The current behavior on  my new uncustomized installation:
> [...]
> Any idea what g+s should be doing? Any more/better information I can
> provide?

What you observe is a bug in Cygwin, plain and simple.  Without going
into too much detail, part of the problem could never be observed with
older coreutils, which we had to live with for much too long in the
Cygwin distro.  The newer coreutils handles permissions slightly
differently and that dropped the mask from the buggy code.

I applied a patch which, hopefully, fixes this problem (in fact, plural,
"these problems").

A new Cygwin test release 3.5.0-0.162.g498fce80ef33 is just being built
and should be up in an hour or so.  You can simply install it via
Cygwin's setup tool as soon as it's on your favorite mirror.

If it works as desired, it will be part of the next Cygwin bugfix
release 3.4.6.


Thanks,
Corinna

Re: chmod g+ws unsuccessful, "NULL SID" icacls missing

[Norton Allen]

On 2/9/2023 4:09 PM, Corinna Vinschen wrote:
> Hi Norton,
>
> On Feb  9 13:25, Norton Allen via Cygwin wrote:
>> On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
>>> I briefly raised this issue months ago and am trying to resolve it again
>>> now.
>>>
>>> What I am trying to do is setup permissions so multiple users on one
>>> machine can share full control over a particular directory hierarchy.
>>>
>>> On Linux I have usually been able to make things work with:
>>>
>>>     $ mkdir shared_dir
>>>     $ chgrp shared_group shared_dir
>>>     $ chmod g+ws shared_dir
>>>     $ umask 2
>>>
>>> User shells are configured with umask 2 so files they create have group
>>> write. Users belong to shared_group. Files and subdirs created under
>>> shared_dir are all in group shared_group. Files moved in retain their
>>> original group, but the group members still have permission to rename or
>>> delete them.
>>>
>>> The problem:
>>>
>>> $ chmod g+ws fails to set the 's' bit, and the resulting icacls output
>>> does not contain any "NULL SID" entries. I am seeing the same problem on
>>> (at least) two different systems setup by my organization. One of these
>>> was just re-imaged and I installed Cygwin yesterday with no customized
>>> configurations. AV is Windows Defender, but I suspect if that were the
>>> culprit, there would have been more noise.
>>>
>>> I suspect there might be a group policy or something that is interfering
>>> with Cygwin's strategy for implementing POSIX permissions. I am pretty
>>> sure this worked correctly at some point in the past.
>>>
>>> Has anyone encountered this?
>>>
>>> Does group policy seem like a likely suspect? Anyone know which
>>> policy(ies)? I think I might be able to get IT to cut me slack if I knew
>>> what to ask for.
>>>
>>> I have also played with using setfacl directly to add permissions, but
>>> as anyone who has read about Cygwin file permissions might guess, that
>>> tends to have mixed/poor results, but I'd be open to any suggestions.
>>>
>> I don't actually have a system on which this is working to compare to, so I
>> am not exactly sure how it is supposed to look when it's working correctly.
>> The current behavior on  my new uncustomized installation:
>> [...]
>> Any idea what g+s should be doing? Any more/better information I can
>> provide?
> What you observe is a bug in Cygwin, plain and simple.  Without going
> into too much detail, part of the problem could never be observed with
> older coreutils, which we had to live with for much too long in the
> Cygwin distro.  The newer coreutils handles permissions slightly
> differently and that dropped the mask from the buggy code.
>
> I applied a patch which, hopefully, fixes this problem (in fact, plural,
> "these problems").
>
> A new Cygwin test release 3.5.0-0.162.g498fce80ef33 is just being built
> and should be up in an hour or so.  You can simply install it via
> Cygwin's setup tool as soon as it's on your favorite mirror.
>
> If it works as desired, it will be part of the next Cygwin bugfix
> release 3.4.6.
>
>
> Thanks,
> Corinna

Corinna,

The fix seems to work like a charm! And I am happy to be wrong about the 
source of the problem.

Re: chmod g+ws unsuccessful, "NULL SID" icacls missing

[Corinna Vinschen]

On Feb 10 11:42, Norton Allen via Cygwin wrote:
> On 2/9/2023 4:09 PM, Corinna Vinschen wrote:
> > On Feb  9 13:25, Norton Allen via Cygwin wrote:
> > > On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
> > > > [...]
> > > > The problem:
> > > > 
> > > > $ chmod g+ws fails to set the 's' bit, and the resulting icacls output
> > > > does not contain any "NULL SID" entries. I am seeing the same problem on
> > > > (at least) two different systems setup by my organization. One of these
> > > > was just re-imaged and I installed Cygwin yesterday with no customized
> > > > configurations. AV is Windows Defender, but I suspect if that were the
> > > > culprit, there would have been more noise.
> > > > [...]
> > > [...]
> > > Any idea what g+s should be doing? Any more/better information I can
> > > provide?
> > What you observe is a bug in Cygwin, plain and simple.  Without going
> > into too much detail, part of the problem could never be observed with
> > older coreutils, which we had to live with for much too long in the
> > Cygwin distro.  The newer coreutils handles permissions slightly
> > differently and that dropped the mask from the buggy code.
> > 
> > I applied a patch which, hopefully, fixes this problem (in fact, plural,
> > "these problems").
> > 
> > A new Cygwin test release 3.5.0-0.162.g498fce80ef33 is just being built
> > and should be up in an hour or so.  You can simply install it via
> > Cygwin's setup tool as soon as it's on your favorite mirror.
> > 
> > If it works as desired, it will be part of the next Cygwin bugfix
> > release 3.4.6.
> 
> Corinna,
> 
> The fix seems to work like a charm! And I am happy to be wrong about the
> source of the problem.

Great, thanks for testing!


Corinna