Mail Archives: cygwin/2015/04/20/05:18:31
--0ZSpXV6RUUo6PuQK
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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?
>=20
> 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?
>=20
> 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.)
>=20
> 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=E2=
=80=90
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
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--0ZSpXV6RUUo6PuQK
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVNMRKAAoJEPU2Bp2uRE+g4oQP/RNfrsNGOjG7AM8ZPRiVWKcV
/xH4ITjpgYaa+QYX9eQaXQR2DMpqfyOxYoBIZfvruf9vhpKW+D3sx/0l6KaUWwd/
I1uVlGeBeyyyFlP6jrpkKaFxGDXk6wGBEM64Nh65i/iFk7rUXm83UP8kb+P+WDol
zZwKM12A3xxW+kGsTrMkufPz48Z8pMGRz0GSj8rPUGkF2qCtXp6zfcVR1vOj0C2r
dr7MDZ7TSvF8C8deilb1NMeUebDU6V+/mIlApg9wSXjOvbGkl9pV6IRcEMfvmeQv
E9j+Pfnio7VgCjffmdy3NhmTzAAWu+GFR2QsUnPjZORZz9hvY/iNcvr90VzfLPfm
OoQ3ccJcV2IQWfzWN6NrMDk9UxWzlhWyB0aJsOwGZMMV1nZZLG6ap4LZ0IYWwtaP
4WVqObACJDup4vvW0URqbT4o7L2GviIHvO6CYiABODuMT3VW+4+/6YVoKiYauDvP
FzOX27yRpcLcSJtwsVv1uBoNmUzUj3DqdlyOKY6gcytYoowN7yek4Pj62B7aghDF
fkmLZlrzxCavFkWlDZzf8nG0W8AtBEpr+qAXEwAxmJRXQnckUKa/5/VWTssQGXnZ
ENU+CzKwfX4+F3Htdhzq7AHzmd4vtg0SQZ6Oo6+XXpsfcElN8SEapd8vH85rzYgI
XMr337aHWD4iAlkE6vo4
=KxhQ
-----END PGP SIGNATURE-----
--0ZSpXV6RUUo6PuQK--
- Raw text -