public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: L A Walsh <cygwin@tlinx.org>
To: Andrey Repin <anrdaemon@yandex.ru>
Cc: cygwin@cygwin.com
Subject: Re: objects created in a dir w/cygwin mangled perms; inherit no-access
Date: Thu, 15 Jul 2021 00:02:28 -0700	[thread overview]
Message-ID: <60EFDD84.8040401@tlinx.org> (raw)
In-Reply-To: <685980612.20210707214357@yandex.ru>



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

  reply	other threads:[~2021-07-15  7:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-04  5:44 L A Walsh
2021-07-04 14:20 ` Andrey Repin
2021-07-06 13:55   ` L A Walsh
2021-07-07 18:43     ` Andrey Repin
2021-07-15  7:02       ` L A Walsh [this message]
2021-07-15  8:23         ` Sam Edge
2021-08-23 19:31           ` L A Walsh
2021-08-24  6:19             ` Sam Edge
2021-07-16  4:44         ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60EFDD84.8040401@tlinx.org \
    --to=cygwin@tlinx.org \
    --cc=anrdaemon@yandex.ru \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).