Is this a valid synopsis of Cygwin Permission Handling?

Is this a valid synopsis of Cygwin Permission Handling?

[KARL BOTTS]

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.


---
Karl Botts, kdbotts@usa.net

Re: 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