Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7

[random user <cnpxzsdwle4m0dkt at gmail dot com>]

Hmm... Seems my Item 1 and Item 2 are more related in your design
thinking than I had realized.

>>> "extended ACLs" (is that the proper phrasing?),
>> (default ACL entries in POSIX speak, inheritable ACEs in Windows)

I'm looking for the term that would distinguish whether on Linux ls
shows a '+' and getfacl shows a mask: line, and controls whether umask
is ignored or respected and how chmod behaves -- which seems on Linux
whether any ACL entry other than those needed to represent the basic
mode are present.  I'll stick with "extended ACLs" for this below;
Google seems to show many hits with this intended meaning on that
phrase.

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

>> 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:

a1) on Linux, if there are any default ACL entries on the parent
    directory, umask is applied to these.  Execute perms are then also
    dropped when creating a new non-directory.

a2) on Linux, if there are no default ACL entries on the parent
    directory, umask is applied to 0777.  Execute perms are then also
    dropped when creating a new non-directory.

b) in current/older Cygwin releases, umask is applied to 0777.
   Execute perms are then also dropped when creating a new
   non-directory.  The result is then combined with any
   to-be-inherited ACL entries from the parent directory.

Does that all seem correct?

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.

Inputs/goals:

a) The above re umask behavior.  Also the two distinct Posix behaviors
   of chmod, it either impacting the primary group "permanently", or
   impacting only the mask.  [Q: Are these the only differences
   between "simple" and "extended ACLs" behavior, as far as actions
   that create ACLs/make changes go?]

b) I note that on Linux it still seems to take explicit user action to
   end up with "extended ACLs" behavior.  At least in my experiences
   so far, new installs aren't typically set up in such a way that
   users would see any such cases, unless/until they create such
   themselves, most likely only via explicit use of setfacl.  So I'm
   interpreting that "extended ACLs" behavior isn't something that
   Linux is trying to push people into using, it's an available option
   but not seeming preferred/forced.  Build and install scripts for
   the various packages are likely not expecting "extended ACLs"
   behavior, and so far it wouldn't seem likely that there'd be a
   major round of rewriting of them all.

   Thus I'm thinking it's likely not so desirable that Cygwin would
   consider existing cases to be ones that get "extended ACLs"
   behavior.  Existing cases would seem better "grandfathered",
   continuing with closer to existing non-"extended ACLs" behavior
   re umask and chmod.

c) The desire of various folk to have some ACL entries always present
   for non-Cygwin maintenance/backup programs.

   And as a subpart of this, a desire by various folk that the
   'visible' mode bits (what's seen in ls and by programs checking for
   'tight' permissions) would ignore these, even if that means that
   that these Cygwin programs aren't seeing all the actual permissions
   granted on the dirs/files.  (I suspect here is where contrary
   opinions might exist.  Those more wanting to use Cygwin to manage
   Windows, rather than as a Posix-compatible environment despite of
   Windows, would likely prefer that all actual permissions are
   visible.)

d) The desire to have some to-be-inherited/default ACL present on a
   directory for non-Cygwin programs to be able to create files in it
   sanely.

e) A desire to provide good Posix setfacl behavior as new
   functionality, but to avoid hassling people who aren't really
   looking for that functionality, want their current environments to
   keep working mostly as-is.  (Not sure if the upwards compatibility
   concen is generally as topmost in Cygwin design thinking/planning
   as I'd think it ought to be.)

Possible flexibility/leverage point vs the current design:

>> Yes, that's a problem.  The underlying problem is that you can't
   distinguish inheritable ACEs created by Cygwin just for the sake of
   Windows applications from inheritable ACEs created explicitely and
   willingly to have the same behaviour for Cygwin apps.  They are
   identical to the bit.

But it seems your new representation for ACLs would give you the
ability to treat ACL entries created by new-version setfacl
differently from any Windows-created or old-Cygwin created ones.  The
presence of your new NULL SID entry, plus then having a DENY present
preceding an allow ACL entry, would seem able to mark the difference.

I've not encountered DENY ACL entries used much on files/dirs in
Windows, prior to your new design.  Am I right in thinking they are
not at all common, that we can perhaps design with an assumption that
folks wouldn't likely be needing DENYs present on their for-non-Cygwin
ACL entries, (c) above?  (Clearly it'd be a possibility that a DENY
might exist, but either error trap, refusing to create "extended ACLs"
if one does, or just document that there might be surprising behavior.
The choice of whether to best include a NULL SID now always or only if
some category (2) items as discussed below are present might depend on
how you wanted to deal with this.)
 
Thus:

What if we logically think of four distinct sets of ACL entries:

1) ACL entries present to represent the simple mode bits, or in Posix
   ACL terms the user::, group::, and other: ones.

   I'm not sure if these are CREATOR OWNER / CREATOR GROUP for the ACL
   entries representing the current file/directories' own, or are the
   actual user and group SIDs (icacls seems to show them as this
   latter, but maybe it's just folded in the user/group names for sake
   of display?), but the discussion re u:: and u:username: being able
   to coexist suggests one way or another you can determine which are
   u::, g::, which are u::username: or g:usersgroup:, yes?

2) Posix-behaved "extended ACLs" entries.

   These would only be ones created by new-version setfacl.

3) "Windows artifacts" ACL entries.

   Any currently-existing ACL entry that's not category (1) or (4)
   would be treated as one of these, even if it had been created by
   old-version Cygwin.  I would see that as a positive for easier
   migration.

   Any new ACL entry added with icacls or Windows GUI would be treated
   as one of these, unless someone puts effort into creating a DENY
   entry as well.  (How well icacls and Windows GUI would behave when
   used to modify your new form of ACL representation is something I
   haven't explored tho.)

4) A base set of to-be-inherited ACL entries present on directories
   for sake of non-Cygwin programs creating files in them.  These
   would be placed by mkdir (as currently), but would also be placed
   when setfacl -k/-b removed default ACLs.

   Use of setfacl explicitly to create any default ACL (which should
   then be category (2)) should best implicitly remove all these.

   It's likely a separable topic, but my own suggestion would be to
   no longer have these dependent on the directory's own mode, but rather
   on new mkdir or setfacl use that would add them, just always set to
     CREATOR OWNER:(OI)(CI)(IO)(F)
     CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA)
     Everyone:(OI)(CI)(IO)(Rc,S,RA)
   This would be to avoid my concern about these not tracking a later
   chmod, and also that giving CREATOR OWNER less than (F) doesn't
   work so well for non-Cygwin programs.

As a possible representation: Category (2) cases would always have a
preceding DENY.  Any non-category (1) entries without a preceding
DENY would be treated as categories (3) or (4).  The primary group
would have a DENY present if needed to represent a mask, which
would only occur if some category (2) case is also present.

Category (1) and (2) ACL entries should follow Posix behavior.

On new file/directory creation, category (4) ACL entries of the parent
directory would be ignored when Cygwin creates a new file/directory.
If any category (2) default ACL entries are present, then umask
behavior (a1) would apply, else (a2).  Then any category (3) ACL
entries would be folded in, remaining category (3) on the new
file/directory.  For a new directory, if there are no category (2)
default ACL entries, category (4) entries would be added for those of
CREATOR OWNER, CREATOR GROUP, Everyone that didn't have a category (3)
to-be-inherited already applied.

Rules for chmod would depend on how you want to deal with category (3)
items.  In 1.7.35 chmod is impacting these, which if I've understood
right has gotten some complaint on the email list.

Possible choices:

a) chmod would impact category (3) entries.  If there are any category
   (2) present, then category (3) would be converted to category (2)
   if chmod 'g-' creates non-empty masks.  Else, following 1.7.35's
   behavior, these would get modified similarly to the primary group.
   Special casing of SYSTEM and ADMINISTRATOR would remain an
   orthogonal design choice.

b) chmod would simply ignore category (3) entries.

If going with (b), then the question would be how to deal with chmod
then not having impact on the visible mode bits display if the
permissions remaining on category (3) ACL entries show through.  A
choice might be to not include category (3) entries in the visible
mode bits.  If doing that, I think I'd suggest getfacl might have an
option to display categories (3) and (4) or not, with a # "comment" as
used by #effective: to not they are non-Posix-behaved.  Maybe whatever
'ls' uses to determine if to show a '+' would also ignore category (3)
and (4) entries presence.

I'm not myself caring much anymore about category (3) cases, either
approach would be fine by me.  I've already cleaned my own directory
trees to not have any category (3)'s.  But it does seem these are a
common topic raised on the email list.  To me, having category (3)
permissions not reflected in ls/find/access()/etc. behavior wouldn't
bother me too much, using icacls isn't so hard.  I'd tend to prefer
that the same commands would have the same visual behavior on Cygwin
as on Linux, even if Cygwin wasn't then reflecting "Windows artifacts"
including even permission grants.  However, I expect others may differ
on that.

I would suggest category (4) behavior is important tho.  Having mkdir
itself put the directory into "extended ACLs" mode for new file
creation in it seems a poor choice, incompatible with Linux behavior.
Having mkdir or setfacl (including -b/-k) create cases with no
to-be-inherited ACLs seems asking for trouble in the use of non-Cygwin
programs.


>> Do you mean the POSIX API? 

Likely I do, I think that's what tar is looking for.

Regarding my earlier Item 3: Glad it helped you spot a bug.  I've
played further with Linux, now think I understand, no longer have
conceptual concerns.

Thanks for considering these thoughts.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple