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

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

[L A Walsh]

Trying to track down exact conditions for a simpler testcase
for a weird error message in tar and ran across this...

in directory 'SI':
/progd/Microsoft/../Tools/Sysinternals> ll -ad SI
drwxrwxr-x+ 1 0 Jul  3 16:28 SI/

w/umask:
>  umask
0002

I make dir 'newdir':

>  mkdir newdir

and ls -lgG shows:

d---rwxr-x+ 1    0 Jul  3 16:40 newdir/

No access for user(me).

I ran into this because trying to enter the directory in
explorer I got no access!  Trying to look at the perms, I
get warnings about the rights possibly being out of order until
eventually, if I want to proceed, it claims it has to reorder them.

This seems to have come from some weird setting that
seems to come from Cygwin, with 5 deny records at the front
for NULL, 3 local accounts and 1 domain account (me)...
and the local accts ... also me of a sort.

Then come various allows, some of them that would seem
to undo some of the denies, but its really dependent on
order -- which explorer says is suspect...

Fine...so the results when I did the "mkdir newdir", were
such that ended up with u-wrx, and no access in explore?

Of course I can overide, but why are such weird acls on
this anyway? -- especially when it doesn't seem to really
work?

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

[Andrey Repin]

Greetings, L A Walsh!

> Trying to track down exact conditions for a simpler testcase
> for a weird error message in tar and ran across this...

> in directory 'SI':
> /progd/Microsoft/../Tools/Sysinternals> ll -ad SI
> drwxrwxr-x+ 1 0 Jul  3 16:28 SI/

> w/umask:
>>  umask
> 0002

> I make dir 'newdir':

>>  mkdir newdir

> and ls -lgG shows:

> d---rwxr-x+ 1    0 Jul  3 16:40 newdir/

> No access for user(me).

The "+" at the end indicates presence of extended permissions.
What getfacl says?

> I ran into this because trying to enter the directory in
> explorer I got no access!  Trying to look at the perms, I
> get warnings about the rights possibly being out of order until
> eventually, if I want to proceed, it claims it has to reorder them.

This is true, that Cygwin sets permissions in a non-canonical order, but
that's the only way to have desired results for certain cases of POSIX
permissions configuration.

> This seems to have come from some weird setting that
> seems to come from Cygwin, with 5 deny records at the front
> for NULL, 3 local accounts and 1 domain account (me)...
> and the local accts ... also me of a sort.

> Then come various allows, some of them that would seem
> to undo some of the denies, but its really dependent on
> order -- which explorer says is suspect...

> Fine...so the results when I did the "mkdir newdir", were
> such that ended up with u-wrx, and no access in explore?

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

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


-- 
With best regards,
Andrey Repin
Sunday, July 4, 2021 17:13:55

Sorry for my terrible english...

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

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

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.

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

[Andrey Repin]

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

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

[L A Walsh]

On 2021/07/07 11:43, Andrey Repin wrote:
>>> 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.
---
	If you have something unexpected happening on your own
computer, and you choose not to find the cause, you really don't
know if it was a virus, malware or some other problem.

	I've had my directory tree mounted the way it is since
Windows XP, and have tried to understand issues about computers
that many term "magick" (or black magick).  Being a computer
scientist, I've always tried to understand what was going on.
I don't always find out quickly, but I often return to problems
that I haven't solved years later to sometimes find the cause, or 
sometimes find the problems have gone away. 

	Considering my life has been about computers, opting out
has really not been an option for me.



> 
>>         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.
---
	Nope... can't be, windows doesn't work that way.
A directory can affect its contents, but permissions that are
inherited can't skip a generation.

	or fstab mount options.
---
	I pretty much use the default:
----
# /etc/fstab
#
#    This file is read once by the first process in a Cygwin
#    process tree. To pick up changes, restart all Cygwin
#    processes.  For a description
#    see https://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
none / cygdrive binary,posix=0,user 0 0
----

> Needs a more thorough investigation. But I think it would easily be avoided by a saner directory layout.
---
	What is more sane, ignoring a problem that was opted out
of for 20 years, or understand what causes problems.

	I can't speak for Windows 10, but through Windows 7,
especially in the X64 world, it makes little to no sense to
cut your cygwin tools off from being able to access and work
on your windows installation.  

	If you have ever boot to a rescue system running from
your hard drive -- you have the choice of using all your cygwin
tools to recover your system, or to just use Windows tools.

	If you have 30+ years of unix/linux/posix experience
with linux/posix tools, does it make any sense to throw that
away when trying to recover your system?  X64 Cygwin tools
work natively when installed at root.  Many of the Windows
tools are still x32 which won't run on a rescue system.

	Linux xfs has 2 acls on directories -- one for the directory
and one that can be the default for contents to inherit.  It's
not identical to windows, but it is similar and if you
understand one, the other isn't that different.  Cygwin
has placed the most emphasis on POSIX compatibility vs.
Windows compatibility.  In some places it could have been
more Windows compatible and still achieved POSIX compat.

	I do know, that if you have several added Deny
acls added to every file, it can mess up default inheritance
on content files.  What windows has added to the mix has to
be deleted -- special perms for creators (user+group).  It's
similar to default perms in linux, but it isn't the same.  It
is messed up, other devs have said so -- cygwin perms will conflict
with windows perms when they are mixed.  They've never tried to
fix that.  The  result are utilities and permissions that 
have 'no access' set for 'creators' (usually owners).  That's
not a desired feature unless you opt out of using the windows
GUI.  But that's the main reason I use it, so what's the point?

	In any event, I know there are bugs in cygwin, but
I don't care enough + know enough about windows development
to fix them.  That doesn't mean I opt out of using Cygwin
or Windows (if I can help it), but it doesn't mean I won't
report problems or bugs when I encounter them (doesn't mean
I will either, depends on time).  Anyway...opting out of
understanding why things are or work they way they do is not
something I can easily do, by nature.  I'm too curious.
(too much so, for the time I have to deal with things!).

:-)
Linda

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

[Sam Edge]

On 15/07/2021 08:02, L A Walsh wrote:

>
>
> On 2021/07/07 11:43, Andrey Repin wrote:
>>
>>> 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.
>
>     If you have ever boot to a rescue system running from
> your hard drive -- you have the choice of using all your cygwin
> tools to recover your system, or to just use Windows tools.
>
After wading through the unsolicited self-congratulation a few observations.

1. You want support from the Cygwin community for problems you're having 
despite having installed it in a way that is expressly discouraged. 
(https://cygwin.com/faq.html#faq.setup.c) Good luck with that.

2. You've not bothered to search the archives or even read the manual, 
specifically https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files but 
instead immediately assume a flaw in the code. Not very scientific ... 
or polite.

(By the way, the permission workaround is another good reason for not 
installing in system root if advice from the authors of Cygwin - Corinna 
et al - isn't enough for you.)

3. Installing Cygwin under, say, C:\cygwin64 does not prevent you from 
using it for recovery.

PEBCAK

-- 

Sam Edge

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

[L A Walsh]

On 2021/07/15 01:23, Sam Edge via Cygwin wrote:
> On 15/07/2021 08:02, L A Walsh wrote:
> 
>>
>>
>> On 2021/07/07 11:43, Andrey Repin wrote:
>>>
>>>> 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.
>>
>>     If you have ever boot to a rescue system running from
>> your hard drive -- you have the choice of using all your cygwin
>> tools to recover your system, or to just use Windows tools.
>>
> After wading through the unsolicited self-congratulation a few 
> observations.
> 
> 1. You want support from the Cygwin community for problems you're having 
> despite having installed it in a way that is expressly discouraged. 
> (https://cygwin.com/faq.html#faq.setup.c) Good luck with that.
----
	I pointed out a problem, didn't ask for support from people
who blindly leap off clifs.

> 
> 2. You've not bothered to search the archives or even read the manual, 
> specifically https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files but 
> instead immediately assume a flaw in the code. Not very scientific ... 
> or polite.
---
	I have read such docs many times in the past. Cygwin is designed
to be a POSIX implementation.  POSIX supports ACLs as Linux implementations
show.  There are tons of ways of getting the behavior I noticed
no matter where you put your cygwin directory.  If you have OS
mount points under your cygwin directory you can have the same problem.
so it isn't specific to having your cygwin dir at root.  I get that
you don't know all the background and assume that the current user
guide tells you everything.  However some of us have been using
Cygwin since before it supported ntsec 
 
> (By the way, the permission workaround is another good reason for not 
> installing in system root if advice from the authors of Cygwin - Corinna 
> et al - isn't enough for you.)
---
	Except that at one point, most of the cygwin developers 
installed cygwin at '/'.  That you don't know that shows how long you've
been using cygwin.

> 3. Installing Cygwin under, say, C:\cygwin64 does not prevent you from 
> using it for recovery.
---
	If you don't have the right options set in the registry, other
directories outside of /windows can be inaccessible.

	I have other reasons for my setup.  My windows system has most
of my files on a remote, linux system.  When I'm using the linux
shell, for example, I can bring up explorer for the directory I'm
in by typing 'explore [opt. path]'.  My Doc dir, among others is the
same on Windows as on Linux ~/Documents or /d/.  If I'm running
a prog on linux, and it asks for a browser, it launches my browser
on Windows.  

	In the past, I had both cygwin32 and cygwin64 installed
in their own directories, because there was a brief time when the 64-bit
version of windows and cygwin didn't have all the functionality of
32-bit cygwin, so automatic invocation of the right version was the only
way to get full functionality on a 64-bit native install.

	My purpose in using Cygwin has been to use my linux experience
and tools to help manage my Windows installation and to use my Windows
system as my desktop for a combined linux+windows system.  That doesn't work
well if I install cygwin in a separate "corner" of the system where it is 
deceived about the root of its file system.  Linux can deal with that
as it supports arbitrary mounting.  Cygwin doesn't in a way that Windows
can see, so Cygwin has to use Windows mounting to have a coherent view
of the file system.

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

[Sam Edge]

On 23/08/2021 20:31, L A Walsh wrote:
 >
 > On 2021/07/15 01:23, Sam Edge via Cygwin wrote:
 >> (By the way, the permission workaround is another good reason for
not installing in system root if advice from the authors of Cygwin -
Corinna et al - isn't enough for you.)
 > ---
 >     Except that at one point, most of the cygwin developers installed
cygwin at '/'.  That you don't know that shows how long you've
 > been using cygwin.

For the record, I've been using Cygwin for twenty years or more. For
that entire period the recommendation has been not to install in C:\ or
the root of any other drive. (I've been using UNIX since 1983 by the way
and Windows since version 3.0 not that it makes any difference to the
discussion.)

 >     I have other reasons for my setup.  My windows system has most
 > of my files on a remote, linux system.

Which can be accessed using //host/path (using S4NFS or SMB) or via
Cygwin fstab mounts regardless of where Cygwin is installed locally.

 > When I'm using the linux
 > shell, for example, I can bring up explorer for the directory I'm
 > in by typing 'explore [opt. path]'.  My Doc dir, among others is the
 > same on Windows as on Linux ~/Documents or /d/.  If I'm running
 > a prog on linux, and it asks for a browser, it launches my browser
 > on Windows.

You're not using a Linux shell. You're using a POSIX-like shell compiled
for Cygwin. It's different. For example '//path' on Cygwin accesses
remote filesystems whereas on Linux it doesn't.

If you're running a program on Linux it'll launch whatever it is
configured to launch.

If you're running a Cygwin program it'll do the same, which with
appropriate use of cygpath can launch Windows Explorer (explorer.exe) or
your browser. For example my EDITOR variable launches Notepad++ and 'git
difftool' launches Windows native KDiff3 and they work for any Cygwin
path not just my C drive, converting to Windows when assembling the
command line to pass to the native applications.

I think Andrey covered the rest of your arguments fairly comprehensively.

--
Sam Edge

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

[Andrey Repin]

Greetings, L A Walsh!



> On 2021/07/07 11:43, Andrey Repin wrote:
>>>> 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.
> ---
>         If you have something unexpected happening on your own
> computer, and you choose not to find the cause, you really don't
> know if it was a virus, malware or some other problem.

I've found the cause, which does not change the fact the documented behavior
was undesirable. This is, after all, whyinstalling Cygwin in a system root is
discouraged.

>         I've had my directory tree mounted the way it is since
> Windows XP, and have tried to understand issues about computers
> that many term "magick" (or black magick).  Being a computer
> scientist, I've always tried to understand what was going on.
> I don't always find out quickly, but I often return to problems
> that I haven't solved years later to sometimes find the cause, or 
> sometimes find the problems have gone away. 

>         Considering my life has been about computers, opting out
> has really not been an option for me.

"Doctor, when I poke my eye with a knife, it pains me!"

>>>         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.
> ---
>         Nope... can't be, windows doesn't work that way.
> A directory can affect its contents, but permissions that are
> inherited can't skip a generation.

>         or fstab mount options.
> ---
>         I pretty much use the default:
> ----
> # /etc/fstab
> #
> #    This file is read once by the first process in a Cygwin
> #    process tree. To pick up changes, restart all Cygwin
> #    processes.  For a description
> #    see https://cygwin.com/cygwin-ug-net/using.html#mount-table

> # This is default anyway:
> none / cygdrive binary,posix=0,user 0 0
> ----

This, basically, tells Cygwin to override Windows permissions manager.
Creating all sort of permission issues for unsuspecting Windows programs.

Saner approach would be to leave Windows permissions to Windows.

none / cygdrive noacl,binary,nouser,posix=0 0 0
C:/Users /home bind noacl,binary,exec,posix=0 0 0
none /tmp usertemp binary,nouser,posix=1 0 0

But then again, consider you have two conflicting permission schemes over
directories on the system drive.

>> Needs a more thorough investigation. But I think it would easily be avoided by a saner directory layout.
> ---
>         What is more sane, ignoring a problem that was opted out
> of for 20 years, or understand what causes problems.

That's baseless assumption. The problem was thoroughly investigated and the
final decision was that the lowest number of workarounds is preferable.

>         I can't speak for Windows 10, but through Windows 7,
> especially in the X64 world, it makes little to no sense to
> cut your cygwin tools off from being able to access and work
> on your windows installation.  

Eh? I have Cygwin in %PATH% and use its tools primarily, even though I have
Git for Windows for example. Which I only use for VS Code.
Exception is curl and tidy, both of which I have native builds.

>         If you have ever boot to a rescue system running from
> your hard drive -- you have the choice of using all your cygwin
> tools to recover your system, or to just use Windows tools.

I have my own rescue system. I'm a support engineer after all. These are tools
of my trade. And for the record, TakeCommand is more useful for rescue tool
than Cygwin. I have both.

>         If you have 30+ years of unix/linux/posix experience
> with linux/posix tools, does it make any sense to throw that
> away when trying to recover your system?

When system is not Linux/UNIX? Absolutely. Use right tool for the job.
I only have 12 or so years of *NIX experience, and I would never ditch a
chance of using bash script to do the work for me, but if I have a choice of
native tool that's almost equivalent in performance, I'd use that.

> X64 Cygwin tools work natively when installed at root.

They work equally well when installed in C:\Programs\Cygwin64. JFYI.

> Many of the Windows tools are still x32 which won't run on a rescue system.

That's why I opted for 64-bit tools where possible.
In my experience, they work faster on 64-bit system, than 32-bit tools, even
if built from same source.

> Linux xfs has 2 acls on directories -- one for the directory
> and one that can be the default for contents to inherit.  It's
> not identical to windows, but it is similar and if you
> understand one, the other isn't that different.  Cygwin
> has placed the most emphasis on POSIX compatibility vs.
> Windows compatibility.  In some places it could have been
> more Windows compatible and still achieved POSIX compat.

I'm familiar with POSIX ACL's.

>         I do know, that if you have several added Deny
> acls added to every file, it can mess up default inheritance
> on content files.  What windows has added to the mix has to
> be deleted -- special perms for creators (user+group).  It's
> similar to default perms in linux, but it isn't the same.  It
> is messed up, other devs have said so -- cygwin perms will conflict
> with windows perms when they are mixed.  They've never tried to
> fix that.  The  result are utilities and permissions that 
> have 'no access' set for 'creators' (usually owners).  That's
> not a desired feature unless you opt out of using the windows
> GUI.  But that's the main reason I use it, so what's the point?

>         In any event, I know there are bugs in cygwin, but
> I don't care enough + know enough about windows development
> to fix them.  That doesn't mean I opt out of using Cygwin
> or Windows (if I can help it), but it doesn't mean I won't
> report problems or bugs when I encounter them (doesn't mean
> I will either, depends on time).  Anyway...opting out of
> understanding why things are or work they way they do is not
> something I can easily do, by nature.  I'm too curious.
> (too much so, for the time I have to deal with things!).

The reasoning for things to work like that is well explained in the
documentation. Though, if you have found a special case that should be
avoided, and it looks like so, things may improve with your help.


-- 
With best regards,
Andrey Repin
Friday, July 16, 2021 7:11:36

Sorry for my terrible english...