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