Re: ACEs and ACLs
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 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: No Win ACLs for NFS? Re: ACEs and ACLs
On Mar 19 08:55, Cedric Blancher via Cygwin wrote: > On Mon, 18 Mar 2024 at 15: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 > > 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
No Win ACLs for NFS? Re: ACEs and ACLs
On Mon, 18 Mar 2024 at 15: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 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 [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACEs and ACLs
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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACEs and ACLs
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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACEs and ACLs
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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACEs and ACLs
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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ACEs and ACLs
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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
