* issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
@ 2015-04-18 5:58 random user
2015-04-18 10:06 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: random user @ 2015-04-18 5:58 UTC (permalink / raw)
To: cygwin
Hi again, Corinna.
I appreciate these recent changes, the more complete Posix ACL support
looks beneficial for sharing/syncing files between Cygwin and Linux
machines, and for more compatible scripting.
But I've noticed a few possibly-concerning items:
Item 1:
>> - I introduced a change in chmod behaviour which is not exactly in
line with POSIX 1003.1e draft 17:
This change looks to me to be somewhat dangerous. I'm concerned it
may lead to granting privileges one doesn't expect to have granted.
And scripts leveraging this would behave noticeably differently on
Cygwin than they do on Linux, leading to extra time to debug/recode.
A simplistic example use case:
# Create scripts for some app, with group set to give httpd or some
# other application login user read and execute privs. For sake of
# brevity, here only showing one directory, but reality would likely
# be a tree of dirs and files. At least to my sensibilities, having
# the primary group be httpd here makes sense in what I'd like to see
# in 'ls', and what I'd like 'find' to be able to find most easily,
# even tho httpd is intended to have fewer privileges than the
# developers group will be given at times on these dirs/files.
mkdir appdir
chgrp httpd appdir
chmod 750 appdir
ls -ald appdir
getfacl appdir
# Give developers write access.
setfacl -m "g:developers:rwx" appdir
ls -ald appdir
getfacl appdir
# Production use period, try to prevent changes.
chmod ugo-w appdir
ls -ald appdir
getfacl appdir
# Development period: Reenable changes by local-machine developers -
# but did NOT intend to enable writes from the http daemon which may
# be up running other applications. On Linux, remains 'group::r-x',
# only mask gets changed.
chmod g+w appdir
ls -ald appdir
getfacl appdir
---
Item 2:
I'm having troubles figuring out how to create a directory that plays
well both for providing old-style umask behavior and as a holder of
files created by non-Cygwin Windows apps.
Cygwin mkdir seems to create some to-be-inherited ACLs, even if the
parent directory has had 'setfacl -k' applied (and so it's clear these
aren't being inherited down, they seem newly added by mkdir or some
library call it makes):
CREATOR OWNER:(OI)(CI)(IO)(F)
CREATOR GROUP:(OI)(CI)(IO)(RX,W,DC)
Everyone:(OI)(CI)(IO)(RX,W,DC)
(The actual permissions in these seem to vary based on the umask
setting and any inherited ACLs at time of directory creation.)
This seems existing behavior in Cygwin, still present in this
test drop.
What I seem to be seeing is that with these present, this test drop
appears to now be treating the directory as having "extended ACLs" (is
that the proper phrasing?), and so now will use these default: ACL
entries to create the permissions for a newly-created-by-Cygwin-app
file rather than using umask. So even with umask = 0, I now get only
0700 on newly created files in a directory that itself has 0700,
rather than 0777 as I get on older Cygwin and on Linux. (What I
actually get seems to vary based on the directory-creation-time umask,
or whatever ACLs the parent directory itself inherited via this
mechanism, as noted in prior paragraph's parenthetical.)
I can use 'setfacl -k .' to remove these, but then if I try to write a
file into the directory using a non-Cygwin program I end up with a
rather strange set of ACLs on it. (I had in past remembered stuff
like "CURRENT SESSION", but doing a test now using 'echo x > file'
under cmd I find I get <my user>(F), cyg_server(F), Administrators(F),
and SYSTEM(F) tho none of cyg_server, Administrators, nor SYSTEM are
present at all in the ACLs of the parent directory, and <my user>
isn't cyg_server.) I suspect the desire to allow non-Cygwin apps to
sanely create files in a Cygwin-created directory is likely the reason
that mkdir is creating these ACL entries.
Would it maybe make sense for 'setfacl -k' to keep/recreate the same
base set of to-be-inherited ACLs that mkdir does, and for the
determination of whether to use umask vs. the default: ACLs to ignore
these? Maybe for better cosmetics, for getfacl to not show these, nor
ls to show these cases only as causing a '+' to appear, so that a
newly-created directory with no ACLs inherited from above would appear
both visually and behaviorally as not using "extended ACLs"?
I note that chmod doesn't keep these to-be-inherited entries in sync
with the directory's mode; they seem stuck at their create-time values
unless changed explicitly with icacls. (And am I right that these
can't be easily changed with setfacl, since the SIDs involved don't
have Cygwin user/group mappings?) This seems true of both this test
drop and older Cygwin. Intuitively this feels not-quite-right, but
seems a separable concern from the above and isn't a current change.
---
Item 3:
It seems to create rather messy/redundant ACLs if one tries to use
setfacl to adjust the owning user's privileges explicitly by user
name. This is also seeming to be interacting with the "Item 1" topic,
leading to surprising grants to the file's primary group (when that's
*not* the same SID as the owning user).
umask 77
mkdir testdir
ls -al testdir
getfacl testdir
icacls testdir
setfacl -m "u:${USER}:rwx" testdir
ls -al testdir
getfacl testdir
icacls testdir
chmod u-w testdir
ls -al testdir
getfacl testdir
icacls testdir
---
Item 4:
Just a question (tho if 'no', then a 'wish list' vote for some
"soonish" future release): Is this coming release likely to provide
the right APIs for ACL handling that we can then build tar enabled to
save/restore ACLs?
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 5:58 issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 random user @ 2015-04-18 10:06 ` Corinna Vinschen 2015-04-19 20:50 ` random user 0 siblings, 1 reply; 5+ messages in thread From: Corinna Vinschen @ 2015-04-18 10:06 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 6914 bytes --] Hi random user (at least a first name would be nice, you know my first name as well, isn't it?), On Apr 17 22:58, random user wrote: > Hi again, Corinna. > > I appreciate these recent changes, the more complete Posix ACL support > looks beneficial for sharing/syncing files between Cygwin and Linux > machines, and for more compatible scripting. > > But I've noticed a few possibly-concerning items: > > Item 1: > > >> - I introduced a change in chmod behaviour which is not exactly in > line with POSIX 1003.1e draft 17: > > This change looks to me to be somewhat dangerous. I'm concerned it > may lead to granting privileges one doesn't expect to have granted. > And scripts leveraging this would behave noticeably differently on > Cygwin than they do on Linux, leading to extra time to debug/recode. > > A simplistic example use case: Ok, I understand the concern here, but I really didn't do that change out of the blue. Maybe I'm just dumb, but I puzzled myself with this behaviour a couple of times. I think that this specific behaviour defined in draft 17 is surprising for the end user. The difference between Linux and Cygwin is that Cygwin users have *lots* of ACLs with default permissions for secondary users by default while on Linux this feature is used in limited circumstances. So without this change, what Cygwin users get is something like this by default: $ touch foo $ chmod g+w foo [switch to another user, member in the same group] $ echo bar >> foo echo: Permission denied A Linux user will never encounter this behaviour in the default case. This is what concerns me a lot and what triggered this change. I'm willing to rethink this change, but for the time being I'd like to keep it this way and test it with a bigger user base (not only the few testers). > Item 2: > > I'm having troubles figuring out how to create a directory that plays > well both for providing old-style umask behavior and as a holder of > files created by non-Cygwin Windows apps. Yeah, I know what you mean. Here's another example of following 1003.1e to the letter while at the same time trying to accommodate native Windows applications... > (The actual permissions in these seem to vary based on the umask > setting and any inherited ACLs at time of directory creation.) > This seems existing behavior in Cygwin, still present in this > test drop. (This is very old code. Windows applications rely on inherited ACLs, so creating Cygwin folders POSIX style, without inhertable ACEs, will result in weird permission settings for files created with native tools) > What I seem to be seeing is that with these present, this test drop > appears to now be treating the directory as having "extended ACLs" (is > that the proper phrasing?), (default ACL entries in POSIX speak, inheritable ACEs in Windows) > and so now will use these default: ACL > entries to create the permissions for a newly-created-by-Cygwin-app > file rather than using umask. ...the 1003.1e part being to apply the umask only if the file does not come with inherited permissions. Due to the default ACEs created by default, all files will have inherited permissions and thus umask is seldomly applied. 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. So it's not clear in this scenario when to apply umask. From the 1003.1e perspective the code is doing the right thing, but the result may, again, be surprising. Any suggestions? Always applying umask, no matter what? > I can use 'setfacl -k .' to remove these, but then if I try to write a > file into the directory using a non-Cygwin program I end up with a > rather strange set of ACLs on it. Typically you get the default DACL from your user token: $USER rwx SYSTEM rwx Admins rwx > I suspect the desire to allow non-Cygwin apps to > sanely create files in a Cygwin-created directory is likely the reason > that mkdir is creating these ACL entries. As outlined above. > Would it maybe make sense for 'setfacl -k' to keep/recreate the same > base set of to-be-inherited ACLs that mkdir does, and for the > determination of whether to use umask vs. the default: ACLs to ignore > these? Maybe for better cosmetics, for getfacl to not show these, nor > ls to show these cases only as causing a '+' to appear, so that a > newly-created directory with no ACLs inherited from above would appear > both visually and behaviorally as not using "extended ACLs"? No. I really don't think so. Again, the point is that you can't inherited ACEs for Windows-only from explicit default ACL entries created by a user. Second guessing here and not showing entries will even be more surprising. > 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? > they seem stuck at their create-time values > unless changed explicitly with icacls. Why icacls? Just use setfacl. > (And am I right that these > can't be easily changed with setfacl, since the SIDs involved don't > have Cygwin user/group mappings?) Hmm, that sounds like you never actually tried it... > Item 3: > > It seems to create rather messy/redundant ACLs if one tries to use > setfacl to adjust the owning user's privileges explicitly by user > name. As on Linux: $ touch foo $ getfacl foo # file: foo # owner: corinna # group: vinschen user::rw- group::--- other::--- $ setfacl -m u:corinna:r-- foo $ getfacl foo # file: foo # owner: corinna # group: vinschen user::rw- user:corinna:r-- group::--- mask::r-- other::--- I found that a chmod u-w then results in permission denied messages when tring to change the permissions back, though. That's clearly a bug. > Item 4: > > Just a question (tho if 'no', then a 'wish list' vote for some > "soonish" future release): Is this coming release likely to provide > the right APIs for ACL handling that we can then build tar enabled to > save/restore ACLs? I don't understand the question. Cygwin provides the low level ACL API from original Solaris. Keep in mind that the orignal code in Cygwin is older than the Linux implementation. Do you mean the POSIX API? If so, I'd be glad if somebody would take a stab at implementing the POSIX API in terms of the underlying Solaris API. Really, *really* glad. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-18 10:06 ` Corinna Vinschen @ 2015-04-19 20:50 ` random user 2015-04-20 9:18 ` Corinna Vinschen 0 siblings, 1 reply; 5+ messages in thread From: random user @ 2015-04-19 20:50 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-19 20:50 ` random user @ 2015-04-20 9:18 ` Corinna Vinschen 2015-04-21 2:27 ` random user 0 siblings, 1 reply; 5+ messages in thread From: Corinna Vinschen @ 2015-04-20 9:18 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 4606 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 2015-04-20 9:18 ` Corinna Vinschen @ 2015-04-21 2:27 ` random user 0 siblings, 0 replies; 5+ messages in thread From: random user @ 2015-04-21 2:27 UTC (permalink / raw) To: cygwin Thanks for the explanation/correction about umask's non-impact if there are default ACL entries. I'm not recalling exactly what I had seen on Linux that made me think there was an impact. >> 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. Sounds like that'll maintain current behavior reasonably, thanks. >> 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. I wasn't trying to suggest chmod should change these. It's mkdir I was wondering about, wondering whether it should stop trying to mirror the directory mode into the "default-defaults", just always set as CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA) Everyone:(OI)(CI)(IO)(Rc,S,RA) I change my mind on this tho, noticing that if on Linux I have a directory that's mode 550 with no other ACL entries yet existing, and do a "setfacl -m 'd:g:adm:rwx' .", the result also includes new default ACL entries for d:u::r-x and d:g::r-x. If mirroring the directory's own mode is the way the Posix-behaved default ACL entries are to be created, it would seem best that the Cygwin-mkdir-created ones would continue same. But I'm still thinking it'd be goodness if setfacl were to create the same to-be-inherited entries as mkdir does if no other to-be-inherited ACL entries end up present, so setfacl would never leave a directory with no to-be-inherited ACL entries and so lead to troubles should a non-Cygwin program create a file in it. >> Sorry, but that sounds much too complicated for my taste. >> 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. What wasn't about the "default-default" entries was intended to see if you might like a possible alternative idea for dealing with SYSTEM, ADMINISTRATORS, and other administrative/Windows-program-purposed ACL entries. Goal is to no longer have these have impact on the visible mode bits, to deal with the topic of prior complaints as you seem now trying to do for SYSTEM and ADMINISTRATORS, but there do seem remaining desires expressed in recent emails to have other SIDs able to be similarly treated. And now also to prevent these alone from triggering the new "extended ACLs" behavior. The thought is rather than special casing by SID, instead separate (via your new use of DENYs, NULL SID entry, etc.) by whether a particular ACL entry has been created/modified by new-version Cygwin setfacl or not. Entries that have/haven't should be able to coexist in the same ACL, marked by presence/absence of a preceeding DENY. Thus any SID could be used for a non-Posix-purpose/behavior ACL entry, and on the flipside should someone desire they could create a Posix-behavior ACL entry for ADMINISTRATORS. For any ACL entry not created/modified by new-version Cygwin setfacl, other than the ones representing the simple mode permissions, Cygwin would simply choose to 'say' "that's not a Posix-behaved one, I'll neither show it nor change it." What if at the Cygwin library/Posix-API level, the acl_*() functions (or I guess their Solaris equivalents in current Cygwin coding) would simply not include these at all? And similarly the permission mode bits would simply not include any impact from these, chmod would never change these? And the rights they provide would be implicitly visible in other APIs only exactly as Linux reflects effects of root's magic rights? The inside-the-library code that reads Windows ACLs would have to filter to simply ignore these entries, the code that writes Windows ACLs would have to merge/retain these entries as-is (possibly removing one if a Posix-behaved entry for same SID were created, that seems a choice you could make either way); might most everything else then just fall out properly? -- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-04-21 2:27 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-18 5:58 issues seen in TEST RELEASE: Cygwin 2.0.0-0.7 random user 2015-04-18 10:06 ` Corinna Vinschen 2015-04-19 20:50 ` random user 2015-04-20 9:18 ` Corinna Vinschen 2015-04-21 2:27 ` random user
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).