group permissions

[Corinna Vinschen]

On Feb 10 20:04, Thomas Wolff wrote:
> 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.
> >[...]
> >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...).

Directory defaults are an entirely different beast.  They should be
followed because otherwise the POSIX default permissions would be just
as broken.  The propagation is using the OS capability and that
shouldn't be changed.

> As a combined approach (with your option 2), chmod could modify only
> those hidden entries that typically come from Windows defaults

That's wild guessing.  You never know if an entry is coming from a
Windows default propagation or an explicit user choice in a POSIX
ACL.  There's a good chance in terms of the SYSTEM entry, but you
can't do that for anything else.

> (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.

They do always (unless "noacl" is given).  As soon as you create a file
or directory in Cygwin, the default permissions from the parent folder
are propagated to the Cygwin-created file or directory, and then the ACL
is tweaked to make it POSIX compliant.  While doing that, the
"inherited" flag in the ACE disappears to follow POSIX rules.  A later
chmod will not be able to distinguish ACEs inherited from Windows or
POSIX parents.

> 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.

That's really not feasible.  It might work in some way for SYSTEM, but
it will already break for the Administrators group.  The latter would
be equivalent to the root group, and a POSIX ACL would add the root
permissions to the group perms without the mask preventing it.

Also, keep in mind that this is a transition problem.  It only requires
a single intervention in a couple of cases (not in general), and we're
going to improve the behaviour in the future.


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/e3837409/attachment.sig>