ACEs and ACLs

ACEs and ACLs

[J. Terry Corbet]

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

I have been using Cygwin for a long, long time.  That said, I would have 
to admit there is a good deal about the architecture and infrastructure 
I have never really investigated which is a huge compliment to those of 
you who maintain this wonderful framework. It mostly just works reliably 
and I've seldom needed to look beneath the covers.

I am now, however, having major difficulties which are attributable to 
two fundamental changes in my environment, so let me first state what 
that is.  I have my private, in-home network configured to share 
multiple workstations and laptops via Ethernet or Wifi using SMB/CIFS 
[Windows Features setting] and access control based on the facts that 
a.) I have the same account name and b.) same password on all devices 
_and_ 3.) I am the administrator of each of them.

For some three decades of different versions of Windows and Cygwin this 
has allowed me to operate from any particular workstation with access to 
almost every storage device on the network no matter to which specific 
processor those devices were attached.  Whether the file permissions 
covering the ability to create or delete a file, read or write a file, 
was coming from a cygwin program or some windows application, even when 
there were some fat partitions and some ntfs partitions, it was nearly 
seamless.

So what has changed?  First, I unfortunately lost a motherboard last 
fall and struggling to recover, I had no real choice but to purchase a 
newer motherboard with a newer processor and the newer motherboard no 
longer supported booting from two Windows 7 instances that had coexisted 
with the primary Windows 10 instance on that hardware.. Next, I had to 
build another new system in order to begin to migrated to Windows 11.  
So, as we speak my shared drives are all on hosts running Windows 10 and 
11.  And Cygwin  -- a 32 bit version, a 64-bit version from about the 
beginning of the pandemic, and the most current 64-bit version  is 
installed -- is installed on some of them.

Now with all that context, for which I apologize, but I think it will be 
essential to understanding and remedying my current inability to 
seamlessly create, modify and delete files.  So, let's move to what 
little I know of how I am supposed to manage that integration of a POSIX 
and a Windows way of managing permissions. Number 1, I have never 
touched etc/fstab -- everything has always had the well-behaved result 
from the single-line default setting in that file.  Number 2, despite my 
attempt to better acquaint myself with these matters, I have now become 
accustomed to using the icacls command both to view the state of the 
ACEs assigned to any given file and to modify them by the use use of the 
/reset command-line argument which always produces the state shown here 
as a result of my just creating a folder in which to test:

cygshoot NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(F)
          NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
          BUILTIN\Administrators:(I)(OI)(CI)(F)
          BUILTIN\Users:(I)(OI)(CI)(RX)

I then create a trivial text file via vim;

vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
             NW10\tcorbet:(R,W,D,WDAC,WO)
             NW10\None:(DENY)(S,X)
             NT AUTHORITY\Authenticated Users:(DENY)(S,X)
             NT AUTHORITY\SYSTEM:(DENY)(S,X)
             BUILTIN\Administrators:(DENY)(S,X)
             BUILTIN\Users:(DENY)(S,X)
             NW10\None:(RX)
             NT AUTHORITY\Authenticated Users:(RX,W)
             NT AUTHORITY\SYSTEM:(RX,W)
             BUILTIN\Administrators:(RX,W)
             BUILTIN\Users:(RX)
             Everyone:(R)

Then I do the same thing using notepad:

FileExp.txt NT AUTHORITY\Authenticated Users:(I)(F)
             NT AUTHORITY\SYSTEM:(I)(F)
             BUILTIN\Administrators:(I)(F)
             BUILTIN\Users:(I)(RX)

vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
             NW10\tcorbet:(R,W,D,WDAC,WO)
             NW10\None:(DENY)(S,X)
             NT AUTHORITY\Authenticated Users:(DENY)(S,X)
             NT AUTHORITY\SYSTEM:(DENY)(S,X)
             BUILTIN\Administrators:(DENY)(S,X)
             BUILTIN\Users:(DENY)(S,X)
             NW10\None:(RX)
             NT AUTHORITY\Authenticated Users:(RX,W)
             NT AUTHORITY\SYSTEM:(RX,W)
             BUILTIN\Administrators:(RX,W)
             BUILTIN\Users:(RX)
             Everyone:(R)

Moving now to a remote workstation, this is what icacls reports:

FileExp.txt NT AUTHORITY\Authenticated Users:(I)(F)
             NT AUTHORITY\SYSTEM:(I)(F)
             BUILTIN\Administrators:(I)(F)
             BUILTIN\Users:(I)(RX)

vimtest.txt NULL SID:(DENY)(Rc,WEA,X,DC)
S-1-5-21-3338163194-2450085813-3368937723-1001:(R,W,D,WDAC,WO)
S-1-5-21-3338163194-2450085813-3368937723-513:(DENY)(X)
             NT AUTHORITY\Authenticated Users:(DENY)(X)
             NT AUTHORITY\SYSTEM:(DENY)(X)
             BUILTIN\Administrators:(DENY)(X)
             BUILTIN\Users:(DENY)(X)
             S-1-5-21-3338163194-2450085813-3368937723-513:(RX)
             NT AUTHORITY\Authenticated Users:(RX,W)
             NT AUTHORITY\SYSTEM:(RX,W)
             BUILTIN\Administrators:(RX,W)
             BUILTIN\Users:(RX)

And here is the status that icacls reports back on the original, owning 
workstation
after having use vim to modify the two files from that remote workstation.

FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
             NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
             NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
             NW10\None:(Rc,S,RA)
             NT AUTHORITY\Authenticated Users:(RX,W)
             NT AUTHORITY\SYSTEM:(RX,W)
             BUILTIN\Administrators:(RX,W)
             BUILTIN\Users:(RX)
             Everyone:(Rc,S,RA)

vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
             NW10\tcorbet:(R,W,D,WDAC,WO)
             NW10\None:(DENY)(S,X)
             NT AUTHORITY\Authenticated Users:(DENY)(S,X)
             NT AUTHORITY\SYSTEM:(DENY)(S,X)
             BUILTIN\Administrators:(DENY)(S,X)
             BUILTIN\Users:(DENY)(S,X)
             NW10\None:(RX)
             NT AUTHORITY\Authenticated Users:(RX,W)
             NT AUTHORITY\SYSTEM:(RX,W)
             BUILTIN\Administrators:(RX,W)
             BUILTIN\Users:(RX)
             Everyone:(R)

If my understanding is correct concerning the precedence handling of an
ACL with multiple ACEs for the same user/ID, this result from grep
on the original, owning workstation would not surprise you:

F:\Dev\cygshoot>grep foo fileexp.txt
grep: fileexp.txt: Permission denied

but it blows me completely away.  Clearly I no longer have an environment
in which I can work on any file from any workstation using any Cygwin
utilities.

What have I messed up?

Re: ACEs and ACLs

[Corinna Vinschen]

On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:
> [...]
> And here is the status that icacls reports back on the original, owning
> workstation
> after having use vim to modify the two files from that remote workstation.
> 
> FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>             NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
>             NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
>             NW10\None:(Rc,S,RA)
>             NT AUTHORITY\Authenticated Users:(RX,W)
>             NT AUTHORITY\SYSTEM:(RX,W)
>             BUILTIN\Administrators:(RX,W)
>             BUILTIN\Users:(RX)
>             Everyone:(Rc,S,RA)
> 
> vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
>             NW10\tcorbet:(R,W,D,WDAC,WO)
>             NW10\None:(DENY)(S,X)
>             NT AUTHORITY\Authenticated Users:(DENY)(S,X)
>             NT AUTHORITY\SYSTEM:(DENY)(S,X)
>             BUILTIN\Administrators:(DENY)(S,X)
>             BUILTIN\Users:(DENY)(S,X)
>             NW10\None:(RX)
>             NT AUTHORITY\Authenticated Users:(RX,W)
>             NT AUTHORITY\SYSTEM:(RX,W)
>             BUILTIN\Administrators:(RX,W)
>             BUILTIN\Users:(RX)
>             Everyone:(R)
> 
> If my understanding is correct concerning the precedence handling of an
> ACL with multiple ACEs for the same user/ID, this result from grep
> on the original, owning workstation would not surprise you:
> 
> F:\Dev\cygshoot>grep foo fileexp.txt
> grep: fileexp.txt: Permission denied
> 
> but it blows me completely away.  Clearly I no longer have an environment
> in which I can work on any file from any workstation using any Cygwin
> utilities.
> 
> What have I messed up?

The problem is that your identity is based on the SID of every single
machine, and the machines don't know the SIDs of other machines.  The
default ACL created in Cygwin is emulating POSIX permissions.  This
becomes a problem when sharing files between machines not in the
same Windows domain.

The workaround is not to use POSIX permissions on shares.  Create
matching mount points in /etc/fstab or /etc/fstab.d/ and add the
"noacl" mount flag:

  https://cygwin.com/cygwin-ug-net/using.html#mount-table

Alternatively, you can also just add an fstab entry for the cygdrive
prefix which adds the "noacl" flag, see

  https://cygwin.com/cygwin-ug-net/using.html#cygdrive

but keep in mind that this also affects local paths if you access
them via the cygdrive prefix.


HTH,
Corinna

Re: ACEs and ACLs

[J. Terry Corbet]

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

Thank you for the greatly needed assistance, but the reference to which 
you have pointed me says that noacl will be ignored in the case of ntfs 
file systems.  All of mine are and that has not changed, neither has the 
default entry in fstab, which seems always to have been:

none /cygdrive cygdrive binary, posix=0, user 0 0

On 2024-03-18 04:41, Corinna Vinschen via Cygwin wrote:
> On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:
>> [...]
>> And here is the status that icacls reports back on the original, owning
>> workstation
>> after having use vim to modify the two files from that remote workstation.
>>
>> FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>>              NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
>>              NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
>>              NW10\None:(Rc,S,RA)
>>              NT AUTHORITY\Authenticated Users:(RX,W)
>>              NT AUTHORITY\SYSTEM:(RX,W)
>>              BUILTIN\Administrators:(RX,W)
>>              BUILTIN\Users:(RX)
>>              Everyone:(Rc,S,RA)
>>
>> vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
>>              NW10\tcorbet:(R,W,D,WDAC,WO)
>>              NW10\None:(DENY)(S,X)
>>              NT AUTHORITY\Authenticated Users:(DENY)(S,X)
>>              NT AUTHORITY\SYSTEM:(DENY)(S,X)
>>              BUILTIN\Administrators:(DENY)(S,X)
>>              BUILTIN\Users:(DENY)(S,X)
>>              NW10\None:(RX)
>>              NT AUTHORITY\Authenticated Users:(RX,W)
>>              NT AUTHORITY\SYSTEM:(RX,W)
>>              BUILTIN\Administrators:(RX,W)
>>              BUILTIN\Users:(RX)
>>              Everyone:(R)
>>
>> If my understanding is correct concerning the precedence handling of an
>> ACL with multiple ACEs for the same user/ID, this result from grep
>> on the original, owning workstation would not surprise you:
>>
>> F:\Dev\cygshoot>grep foo fileexp.txt
>> grep: fileexp.txt: Permission denied
>>
>> but it blows me completely away.  Clearly I no longer have an environment
>> in which I can work on any file from any workstation using any Cygwin
>> utilities.
>>
>> What have I messed up?
> The problem is that your identity is based on the SID of every single
> machine, and the machines don't know the SIDs of other machines.  The
> default ACL created in Cygwin is emulating POSIX permissions.  This
> becomes a problem when sharing files between machines not in the
> same Windows domain.
>
> The workaround is not to use POSIX permissions on shares.  Create
> matching mount points in /etc/fstab or /etc/fstab.d/ and add the
> "noacl" mount flag:
>
>    https://cygwin.com/cygwin-ug-net/using.html#mount-table
>
> Alternatively, you can also just add an fstab entry for the cygdrive
> prefix which adds the "noacl" flag, see
>
>    https://cygwin.com/cygwin-ug-net/using.html#cygdrive
>
> but keep in mind that this also affects local paths if you access
> them via the cygdrive prefix.
>
>
> HTH,
> Corinna
>

Re: ACEs and ACLs

[Corinna Vinschen]

On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> Thank you for the greatly needed assistance, but the reference to which you
> have pointed me says that noacl will be ignored in the case of ntfs file
> systems.

No, it doesn't say that.  It says

  "The flag is ignored on NFS filesystems."
                          ^^^
                        not NTFS

> All of mine are and that has not changed, neither has the default
> entry in fstab, which seems always to have been:
> 
> none /cygdrive cygdrive binary, posix=0, user 0 0

Well, the code in question hasn't changed for years either.


¯\_(ツ)_/¯
Corinna

Re: ACEs and ACLs

[J. Terry Corbet]

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


Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for 
confirming that  nothing has changed with regards to these matters; 
clearly it is some change in the way Windows 11 tries to cooperate with 
Windows 10 in the case of mapped network drives being using in the file 
sharing mode wherein remote users must have ids and passwords on the 
target drives -- which they do and always have, but the key ACE entry 
known as NT AUTHORITY\Authenticated Users is correctly specified after 
performing an icacls /reset, but is not longer correctly set after 
editing a file with vim across the network.  I'll keep looking and 
trying to  learn.  Thank you.

On 2024-03-18 08:43, Corinna Vinschen via Cygwin wrote:
> On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
>> Thank you for the greatly needed assistance, but the reference to which you
>> have pointed me says that noacl will be ignored in the case of ntfs file
>> systems.
> No, it doesn't say that.  It says
>
>    "The flag is ignored on NFS filesystems."
>                            ^^^
>                          not NTFS
>
>> All of mine are and that has not changed, neither has the default
>> entry in fstab, which seems always to have been:
>>
>> none /cygdrive cygdrive binary, posix=0, user 0 0
> Well, the code in question hasn't changed for years either.
>
>
> ¯\_(ツ)_/¯
> Corinna
>

Re: ACEs and ACLs

[Corinna Vinschen]

On Mar 18 09:23, J. Terry Corbet via Cygwin wrote:
> 
> Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for confirming
> that  nothing has changed with regards to these matters; clearly it is some
> change in the way Windows 11 tries to cooperate with Windows 10 in the case
> of mapped network drives being using in the file sharing mode wherein remote
> users must have ids and passwords on the target drives -- which they do and
> always have, but the key ACE entry known as NT AUTHORITY\Authenticated Users
> is correctly specified after performing an icacls /reset, but is not longer
> correctly set after editing a file with vim across the network.  I'll keep
> looking and trying to  learn.  Thank you.

Please add the "noacl" flag where you need it and try again.  The result
is using the standard Windows security, so you should see what you
expect in that case.


Thanks,
Corinna

No Win ACLs for NFS? Re: ACEs and ACLs

[Cedric Blancher]

On Mon, 18 Mar 2024 at 15:43, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> > Thank you for the greatly needed assistance, but the reference to which you
> > have pointed me says that noacl will be ignored in the case of ntfs file
> > systems.
>
> No, it doesn't say that.  It says
>
>   "The flag is ignored on NFS filesystems."
>                           ^^^
>                         not NTFS

Do ACLs work for NFS in Cygwin, or are they turned off for NFS?

I recall the Exceed (now OpenText) docs say that Exceed NFSv4 for
Windows supports ACLs, but they are defunct for Cygwin2. Is this true?

I'm also asking because the ms-nfs41-client Windows NFSv4.1 driver now
has ACL support (like the Exceed NFSv4 driver), but it would be
frustrating if Cygwin just turns this off.
Or maybe I am misinterpreting this... @Corinna Vinschen?

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

Re: No Win ACLs for NFS? Re: ACEs and ACLs

[Corinna Vinschen]

On Mar 19 08:55, Cedric Blancher via Cygwin wrote:
> On Mon, 18 Mar 2024 at 15:43, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> > > Thank you for the greatly needed assistance, but the reference to which you
> > > have pointed me says that noacl will be ignored in the case of ntfs file
> > > systems.
> >
> > No, it doesn't say that.  It says
> >
> >   "The flag is ignored on NFS filesystems."
> >                           ^^^
> >                         not NTFS
> 
> Do ACLs work for NFS in Cygwin, or are they turned off for NFS?

NFS uses the unofficial fattr3 interface to fetch real stat(2) info from
the remote FS, see
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/local_includes/nfs.h
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/nfs.cc#n19

> I'm also asking because the ms-nfs41-client Windows NFSv4.1 driver now
> has ACL support (like the Exceed NFSv4 driver), but it would be
> frustrating if Cygwin just turns this off.

Cygwin "doesn't turn them off".  Cygwin recognizes the filesystem as
being an NFS filesystem and uses special non-Windowsy access methods
provided by the MS_NFS client.

If you want ACL support for the NFSv4 client, I made a couple of
suggestions how to integrate stuff in Cygwin in November:
https://cygwin.com/pipermail/cygwin-developers/2023-November/012692.html


Corinna

Re: ACEs and ACLs

[J. Terry Corbet]

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

This is a somewhat belated reply to your emails concerning my troubles 
with ACLs.  It is belated because the environment which I attempt to 
manage via a single administrative account looking at all mounted file 
systems as if they were local to whichever workstation I happen to be 
working from is rather large after several decades of evolution of 
hardware, bioses and operating systems and has taken me this much time 
to apply the recommended fstab setting and test against all the 
different source and target destinations.  [My environment is actually 
rather minuscule as compared to what many professional sys admins 
accomplish daily in using Cygwin in their corporate environments with 
hundreds of users, but pretty large for a private, home network.]

So, the primary purpose of this follow-up is to thank you for the 
'noacl' advice and to confirm that I am back to having the necessary 
controls.  Thank you.  But, while it is true that I have accomplished my 
task, in a low priority back-drop, if you have the time, I would 
appreciate being pointed to any documentation or tutorials that might 
help me understand the conundrum with which the experience leaves me.  
Namely:

Even with noacl specified, the result of modifying some simple text file 
-- either locally or remotely -- causes some perturbation in the 
resulting set and order of ACEs in the ACL for that file versus what is 
the result if I use some native, non-cygwin software to perform 
precisely the same modification -- again, either operating locally or 
remotely.

This lack of real understanding on my part could be looked at from these 
two questions that I have:

A.  If noacl is _not_ the default setting for a Cygwin install, it would 
seem that the existing handling of ACLs must meet most of the user 
community's needs.  For what sorts of networks and/or environments -- 
which must differ from mine as being comprised solely of Windows Mapped 
Network Drives having ntsf partitions -- does the fstab option of acl 
work better than noacl?

or, alternately

B.  Are the differences that can be observed in the resulting ACL state 
of a simple text file being 'touched' by a native Windows executable and 
a similar Cygwin executable only differences in style or syntactical 
preference but no actual difference in the suite of permissions 
available to both local and remotely authenticated users?  [I have been 
able to discern, for example, differences between explicit and inherited 
specifications, but there are also differences which derive, as it seems 
from the use of <perms> specified in what the icacls documentation page 
describes as "basic" as contrasted with "advanced" permissions.]

Thanks for whatever you can suggest on my non-critical, low-priority 
request for additional information.

On 2024-03-18 08:43, Corinna Vinschen via Cygwin wrote:
> On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
>> Thank you for the greatly needed assistance, but the reference to which you
>> have pointed me says that noacl will be ignored in the case of ntfs file
>> systems.
> No, it doesn't say that.  It says
>
>    "The flag is ignored on NFS filesystems."
>                            ^^^
>                          not NTFS
>
>> All of mine are and that has not changed, neither has the default
>> entry in fstab, which seems always to have been:
>>
>> none /cygdrive cygdrive binary, posix=0, user 0 0
> Well, the code in question hasn't changed for years either.
>
>
> ¯\_(ツ)_/¯
> Corinna
>