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