issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
Corinna Vinschen
corinna-cygwin@cygwin.com
Mon Apr 20 09:18:00 GMT 2015
On Apr 19 13:50, random user wrote:
> >>> I note that chmod doesn't keep these to-be-inherited entries in
> sync with the directory's mode;
> >>Yep. Did you check against Linux behaviour?
>
> The difference to my eye is that on Linux there is no such
> to-be-inherited CREATOR OWNER ACL entry created implicitly by mkdir.
> If there is one existing, it's because it was created explicitly with
> setfacl, so seems more the user's responsibility to maintain.
Yes, but Linux doesn't have to maintain native Windows tools. I would
rather not have these default entries but they are there for ages and
they seem to be useful to people. So what's the point? On Linux
the "default-default" entries are not changes with chmod, and on Cygwin
they aren't either. And that's the right thing to do on both systems.
A chmod on a dir never influences the mask of files created in that
directory.
> >> Any suggestions? Always applying umask, no matter what?
>
> Please, no. That would create a behavior pattern quite different than
> Linux's. I don't myself like some aspects of the Linux/Posix
> behavior, but, at least to me, having Cygwin behave compatibly so that
> code/scripts behave the same on Cygwin as on Linux is way more
> important. (Please read this paragraph also as my reply to you re the
> Item 1 topic.)
>
> Tho, to be precise: I think I am seeing on Linux that umask is always
> applied, just it is applied differently depending on whether any
> default ACL entries are present on the parent directory:
http://linux.die.net/man/5/acl explains it:
If a default ACL is associated with a directory, the mode parameter to
the functions creating file objects and the default ACL of the directory
are used to determine the ACL of the new object:
1. The new object inherits the default ACL of the containing directory
as its access ACL.
2. The access ACL entries corresponding to the file permission bits are
modified so that they contain no permissions that are not contained
in the permissions specified by the mode parameter.
If no default ACL is associated with a directory, the mode parameter to
the functions creating file objects and the file creation mask (see
umask(2)) are used to determine the ACL of the new object:
1. The new object is assigned an access ACL containing entries of tag
types ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER. The permissions of
these entries are set to the permissions specified by the file cre‐
ation mask.
2. The access ACL entries corresponding to the file permission bits are
modified so that they contain no permissions that are not contained
in the permissions specified by the mode parameter.
Bottom line: Either the parent has default perms, or umask is applied.
> As to a suggestion.... OK, I'll toss out a strawman. Maybe it'll be
> food for thought, parts of it useful, even if you don't like/choose
> the entire approach. Please expect/forgive some possible glitches as
> this isn't my direct area of expertise.
> [...]
Sorry, but that sounds much too complicated for my taste.
Let me simplify this a bit. I'm only concerned about the behaviour of
the underlying functions in Cygwin for this, and it should be *simple*
so that the logic isn't too confusing and still understood in a year.
From the new code's perspective there are two kinds of ACLs, old
or native Windows ones, and new ones.
Problem: We need those three inheritable ACEs for native tools,
When creating a new file, it will inherit these ACEs. On each
file creation, Cygwin checks the ACL and pulls it straight again.
We would like to allow file creation to recognize the created
ACL as being a "standard" ACL and apply umask.
For new-style ACLs it looks easy: We could define an extra bit in the
inheritable DENY NULL ACE. if the bit is set (after mkdir) Cygwin
applies umask for files created within. If not (after setfacl) it
doesn't.
That leaves the existing, Cygwin-created ACLs. I think we should
compromise here.
If the incoming, inherited ACL contains the three entries for user,
group, and other, it's with very high probability inherited from a
Cygwin created directory. If the inherited ACL contains nothing else,
we're going to apply umask, otherwise we don't.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150420/bd2632bb/attachment.sig>
More information about the Cygwin
mailing list