Re: objects created in a dir w/cygwin mangled perms; inherit no-access

[L A Walsh <cygwin@tlinx.org>]

On 2021/07/04 07:20, Andrey Repin wrote:
> The "+" at the end indicates presence of extended permissions.
---
	Ya, that's what I was referring to when I wrote about
having 5 deny records at the front, though that didn't necessarily
stand out. ⍨  

	Aside from the extended permissions, though, the net result 
was me getting a 'no access' when I tried to look into the
directory with explorer. While I did have access via a local
shell, I also have no-access from bash on a remote system (the 
samba domain controller on linux):

  > echo -n $(uname -n):;id |sed 's/groups.*//'
  Ishtar:uid=5013(law) gid=201(lawgroup)
  > ls -l newdir
  ls: reading directory 'newdir': Permission denied
  > ls -dl newdir
  dr-xrwxr-x 2 law lawgroup 0 Jul  6 05:20 newdir/

On local machine, same:

  > echo -n $(uname -n):;id |sed 's/groups.*//'
  Athenae:uid=5013(Bliss\law) gid=201(Bliss\lawgroup) 
  ls -dxlF newdir
  d---rwxr-x+ 1 Bliss\law Bliss\lawgroup 0 Jul  6 05:20 newdir/

>
> What getfacl says?

# file: newdir
# owner: Bliss\law
# group: Bliss\lawgroup
user::---
user:root:---
user:law:---
user:Astara:---
group::rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask::rwx
other::r-x
default:user::---
default:user:root:---
default:user:law:---
default:user:Astara:---
default:group::rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask::rwx
default:other::r-x

> What is "progd" ? Did you mount some directory into Cygwin tree?

Sorta, actually the cygtree mounted at 'C:\'. 

So 2 Junctions and 1 symlinkd

/Progd  => /ProgramData/
/Prog   => /Program Files (x86)/
/Prog64 => /Program Files/
> 
>> Of course I can overide, but why are such weird acls on
>> this anyway? -- especially when it doesn't seem to really
>> work?
> 
> Probably because of interpretation of the original Windows permissions.
---
	Not exactly, I don't think.
Windows doesn't add "DENY" entries up front.
Seems like there should be a better way since MS's 
subsystem for UNIX didn't seem to use all those 
DENY entries that I ever saw.  Am guessing they
somehow came from those default CREATOR U/G entries
on the parent directory.  This problem has been
around for a few years.

	Certainly, having it create no-access dirs
for the user isn't desirable.  I'm betting that they'd
be denied locally as well if my local user didn't
have admin override rights.