This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]