Is this a valid synopsis of Cygwin Permission Handling?

[Ken Brown]

On 6/18/2020 12:15 PM, KARL BOTTS via Cygwin wrote:
> 
> I wrote the following to a colleague in a private chat channel. Colleague is
> pure Windows: knows little of cygwin or Linux.  He helps me with hardware and
> Windows.
> 
> We had gotten the WinExplorer dialog saying: "The permissions on volume I: are
> incorrectly ordered, which may cause some entries to be ineffective." This was
> after I had run, with cygwin, 'chmod -R 777 .' in the root of that drive.
> 
> I am not complaining, reporting a bug, or anything like that. I am only asking
> the cygwin experts, whether my synopsis of cygwin permission handling, is
> reasonably and logically correct.
> 
> Thanks.
> 
> 
> #################
> 
> Karl Botts, [18.06.20 09:17]
> On that dialog box: I must confess, you should know: I may have caused that,
> by running in root of I: drive, aka in I:/  :
> 
> chmod -R 777 .
> 
> I did that _after_ screwing around with WinExplorer security dialogs. Was not
> getting anywhere, so I tried the chmod out of desperation. Probably should not
> have.
> 
> How cygwin works, with respect to permissions:
> 
> When the first cygwin1.dll is launched (one is being loaded into a process,
> and no other is loaded), it queries from WinDomainController, all security
> info it can get. Including SIDs, ACLs, practically everything. That
> cygwin1.dll builds, in  shared memory private to cygwin, a database expressing
> all that data, in Linux terms. That database emulates what a Linux kernel
> reads from /etc/passwd, /etc/groups, more places, including other hosts.
> 
> All cygwin processes started as descendants of that first process, are passed
> pointer to that DB in shm. (That DB is built just once.) (Remember, in
> Linux/cygwin model, every process is a child of some other process.)
> Thereafter, that DB is almost all a cygwin process knows about perms. I think,
> occasionally, it may call to DomainController again, or to refresh, but tries
> to avoid that, because is very slow. (If every cygwin process queried
> DomainController, would be unacceptably slow.)
> 
> Problem is that emulation, Linux perms <==> Win perms, is not perfect.  A few
> concepts in each, unknown to other.
> 
> In particular: in Win, the AccessControlEntries in an AccessControlList, must
> be in a certain order, or the ACL is invalid. No such concept in Linux: all
> orders valid. When ACL is invalid for that reason, WinExplorer is known to be
> helpless, hence dialog above. Per cygwin mailing list, Win program
> 'icacls.exe' can straighten that out. But requires extreme complex commands to
> icacls; has varied over time; me not know exactly how to do it. So I get
> stuck.
> 
> What 'chmod -R 777 .' means is: Assign complete Read,Write,Execute perms, for
> all of User,Group,Other, from current working dir (the .), recursively, all
> the way down. To all files, all dirs, all everything.
> 
> Those concepts of 'complete' and 'all' and 'recursively all the way down', do
> not map perfectly to Windows. It seems to refuse to believe that intent.
> Somehow, some ACLs wind up in 'wrong ACE order' state. WinExplorer now
> helpless: you get that dialog. Snafu.
> 
> I think I did that.

I haven't read this carefully, but I did notice one inaccuracy.  It's not true 
that the Windows ACEs must be in a certain order or the ACL is invalid.  Windows 
prefers a certain order, in which case the ACL is called "canonical".  But 
Windows deals perfectly well with non-canonical ACLs, even though Windows 
Explorer complains.  See

   https://cygwin.com/cygwin-ug-net/ntsec.html

for details, as well as for an explanation of why Cygwin sometimes produces 
non-canonical ACLs.

Ken