This is the mail archive of the
mailing list for the Cygwin project.
Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
- From: random user <cnpxzsdwle4m0dkt at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 19 Apr 2015 13:50:51 -0700
- Subject: Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
- Authentication-results: sourceware.org; auth=none
- References: <5531F272 dot 4070803 at gmail dot com> <20150418100612 dot GK3657 at calimero dot vinschen dot de>
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
>>> 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.
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
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
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.)
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
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
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.
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
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
>> 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
Thanks for considering these thoughts.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple