issues seen in TEST RELEASE: Cygwin 2.0.0-0.7

issues seen in TEST RELEASE: Cygwin 2.0.0-0.7

[random user]

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

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

[Corinna Vinschen]

[-- 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 --]

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

[random user]

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

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

[Corinna Vinschen]

[-- 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 --]

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

[random user]

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