group permissions

Tue Feb 10 09:21:00 GMT 2015

On Feb 9 21:20, Thomas Wolff wrote:
> Am 09.02.2015 um 10:14 schrieb Corinna Vinschen:
> >On Feb 9 00:03, Thomas Wolff wrote:
> >>With 1.7.34-6:
> >>>- the fixes in POSIX ACL handling and the effect this has on the standard
> >>> POSIX group permissions, as well as the accompanying new setfacl(1)
> >>> options -b/--remove-all and -k/--remove-default.
> >>>
> >>>Seehttps://cygwin.com/cygwin-ug-net/using-utils.html#setfacl
> >>>andhttps://cygwin.com/faq.faq.html#faq.using.ssh-pubkey-stops-working
> >>>andhttps://cygwin.com/faq.faq.html#faq.using.same-with-rhosts
> >>[...]
> >ls shows the primary group of the file and that's not going to change.
> >The hint that more permissions are given is the '+' sign appened to the
> >permission bits.
> I checked on a Ubuntu system where behaviour is more intuitive by some
> functionally added by chmod; it implicitly modifies the “mask” entry to
> achieve exactly the effect most likely to be desired by chmod (showing only
> the group-relevant output lines of getfacl below):

This is effectively the kernel, not only chmod on Ubuntu. chmod(1)
simply calls fchmodat(2). This always influences the ACL_MASK entry
if there is one.
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.
Corinna
-- 
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150210/ff4587ac/attachment.sig>