ACEs and ACLs
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)
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
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
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
