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