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: group permissions

Am 10.02.2015 um 10:21 schrieb Corinna Vinschen:
Here's the problem:  Windows doesn't support an ACL_MASK entry, nor
anything even remotely resembling it.

What does that mean for us?

When reading permissions from a Windows ACL, the ACL_MASK entry can only
be computed from the given values.  The ACL_MASK entry can not be written.

If Cygwin would like to emulate writing an ACL_MASK entry and the Linux
kernel way of writing an ACL_MASK via chmod(2), there would be two ways
to implement that:

o One way would be to fake the mask value by adding an ACL entry with an
   otherwise unused SID.  Cygwin already uses an ACE with the NULL SID
   (S-1-0-0) to emulate S_ISUID, S_ISGID, S_ISVTX, the latter of which
   actually works, the first two just being fake.  We could use the NULL
   SID for ACL_MASK as well.

   However, this fake is somewhat dangerous.  The current implementation
   computes the mask value and adds it to the group permissions, because
   that reflects reality much better than the old implementation.  The
   permissions on the files *are* open to other users and thus a
   security- conscious, but not ACL-aware application like SSH should
   now.  If we fake ACL_MASK as described above, we're not better off
   than with the old implementation.  The NULL SID would just fake tight
   permissions, in reality the permissions are still open.

o The other way to emulate writing an ACL_MASK entry would be to drop
   permissions from all groups and secondary users so they match the
   desired mask value.  This is secure, but in contrast to the other
   solution it would change the secondary permissions permanently.
   Changing the mask back would not change the permissions of the
   secondary ACL entries back.

And a third one, which just occured to me after writing the above:

o Cygwin could emulate the mask by adding an Access-denied ACE for the
   authenticated user SID (S-1-5-11) right after the primary group entry.
   The permission in this ACE are the x'or value of the permissions
   given in the mask.  Such an ACL would basically look like this:

     primary user   rw-
     primary group  r--
     S-1-5-11       -wx deny
     some-group1    rwx
     some-user2     rw-
     Everyone       r--

   The effect would be almost (bit not quite exactly) as if a mask
   value of 'r--' is given.  Since the other groups and users are
   authenticated users, this would effectively disallow them the
   access denied by our "authenticated user mask".

   If the authenticated user SID doesn't work as desired, the fallback
   would be Users (S-1-5-32-545).

I'm open to discuss this further.  It needs implementing, of course.
Thanks for the extensive explanation. Considering that others have problems with the apparent âchmod does not work anymoreâ as well, I would vote even for a âhackedâ change. My preference at this time would be option 2 because itâs easier to understand than option 3 (and who cares to preserve entries not set by cygwin but imposed by Windows default ACLs) but maybe option 3 would be more âcorrectâ.

Another (or additional) option could be to (optionally?) ignore Windows directory defaults when creating a new file (and distinguish them from other default entries that may have been added explicitly...).

As a combined approach (with your option 2), chmod could modify only those hidden entries that typically come from Windows defaults (or those that are parent directory defaults at the time of the chmod), so chmod would âwork againâ at least for those users that donât touch ACLs themselves.

Most of this doesnât resolve the issues with applications that choke on more permissive group permissions than expected (which seems to be the issues in other threads). To mitigate this, I would suggest to ignore the (Windows) system entries (group:SYSTEM, group:Authenticated Users, group:root ?) for the composition of the visible group flags.


Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprÃft.

Problem reports:
Unsubscribe info:

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