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

[Andrey Repin <anrdaemon@yandex.ru>]

Greetings, L A Walsh!

> 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:\'. 

Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally
opted out of it.

> 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.

It may be something in the parent directory or fstab mount options.
Needs a more thorough investigation. But I think it would easily be avoided by
a saner directory layout.


-- 
With best regards,
Andrey Repin
Wednesday, July 7, 2021 21:38:20

Sorry for my terrible english...