group permissions

group permissions

[Thomas Wolff]

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
Group permissions are now composed of multiple ACL entries, like:
-rw-rwx---+ 1 towo Domain Users   128 Feb  5 13:36 x
with ACL:
# file: x
# owner: towo
# group: Domain Users
user::rw-
group::r-x
group:SYSTEM:rwx
mask:rwx
other:---

chmod g-wx does not work on x, only after setfacl -d group:SYSTEM x ,
the g-w bit is gone.
This is surprising behaviour (and has been discussed in a specific
context in another thread);
the explanation is hidden in only roughly related sections of the user
guide (setfacl) or even the FAQ,
and is not found in the section Permissions and Security where one would
look first;
I suggest to add an illustrative section there.

However, I am not yet convinced that the explanation makes it less
surprising from a POSIX point of view
because the file does not have the group 'SYSTEM' which is responsible
for the g+wx flags.
Maybe ls -l should display a more permissive group (in the example case
SYSTEM rather than Domain Users)
to give the user a hint? How is this handled on other ACL systems? (I
can check next week.)

Thomas

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

Re: group permissions

[Andrey Repin]

Greetings, Thomas Wolff!

> 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
> Group permissions are now composed of multiple ACL entries, like:
> -rw-rwx---+ 1 towo Domain Users   128 Feb  5 13:36 x
> with ACL:
> # file: x
> # owner: towo
> # group: Domain Users
> user::rw-
> group::r-x
> group:SYSTEM:rwx
> mask:rwx
> other:---

> chmod g-wx does not work on x, only after setfacl -d group:SYSTEM x ,
> the g-w bit is gone.
> This is surprising behaviour (and has been discussed in a specific
> context in another thread);
> the explanation is hidden in only roughly related sections of the user
> guide (setfacl) or even the FAQ,
> and is not found in the section Permissions and Security where one would
> look first;
> I suggest to add an illustrative section there.

Perhaps, a link to https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working
would suffice.

> However, I am not yet convinced that the explanation makes it less
> surprising from a POSIX point of view because the file does not have the
> group 'SYSTEM' which is responsible for the g+wx flags.
> Maybe ls -l should display a more permissive group (in the example case
> SYSTEM rather than Domain Users) to give the user a hint? How is this
> handled on other ACL systems? (I can check next week.)

See the abovementioned link.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 09.02.2015, <07:07>

Sorry for my terrible english...


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

Re: group permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

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
> Group permissions are now composed of multiple ACL entries, like:
> -rw-rwx---+ 1 towo Domain Users   128 Feb  5 13:36 x
> with ACL:
> # file: x
> # owner: towo
> # group: Domain Users
> user::rw-
> group::r-x
> group:SYSTEM:rwx
> mask:rwx
> other:---
> 
> chmod g-wx does not work on x, only after setfacl -d group:SYSTEM x ,
> the g-w bit is gone.  This is surprising behaviour (and has been
> discussed in a specific context in another thread); the explanation is
> hidden in only roughly related sections of the user guide (setfacl) or
> even the FAQ, and is not found in the section Permissions and Security
> where one would look first; I suggest to add an illustrative section
> there.

Yes, sure, why not.  Any idea for a patch?

> However, I am not yet convinced that the explanation makes it less
> surprising from a POSIX point of view because the file does not have
> the group 'SYSTEM' which is responsible for the g+wx flags.  Maybe ls
> -l should display a more permissive group (in the example case SYSTEM
> rather than Domain Users) to give the user a hint? How is this handled
> on other ACL systems? (I can check next week.)

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: group permissions

[Thomas Wolff]

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
>> Group permissions are now composed of multiple ACL entries, like:
>> -rw-rwx---+ 1 towo Domain Users   128 Feb  5 13:36 x
>> with ACL:
>> # file: x
>> # owner: towo
>> # group: Domain Users
>> user::rw-
>> group::r-x
>> group:SYSTEM:rwx
>> mask:rwx
>> other:---
>>
>> chmod g-wx does not work on x, only after setfacl -d group:SYSTEM x ,
>> the g-w bit is gone.  This is surprising behaviour (and has been
>> discussed in a specific context in another thread); the explanation is
>> hidden in only roughly related sections of the user guide (setfacl) or
>> even the FAQ, and is not found in the section Permissions and Security
>> where one would look first; I suggest to add an illustrative section
>> there.
> Yes, sure, why not.  Any idea for a patch?
>
>> However, I am not yet convinced that the explanation makes it less
>> surprising from a POSIX point of view because the file does not have
>> the group 'SYSTEM' which is responsible for the g+wx flags.  Maybe ls
>> -l should display a more permissive group (in the example case SYSTEM
>> rather than Domain Users) to give the user a hint? How is this handled
>> on other ACL systems? (I can check next week.)
> 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):

Cygwin:

 > ls -l x; getfacl x
-rw-r--r-- 1 me Domain Users 0 Feb  9 15:04 x
group::r--

 > setfacl -m group:Users:rwx x
 > ls -l x; getfacl x
-rw-rwxr--+ 1 me Domain Users 0 Feb  9 15:04 x
group::r--
group:Users:rwx
mask:rwx

 > chmod g-wx x
 > ls -l x; getfacl x
-rw-rwxr--+ 1 me Domain Users 0 Feb  9 15:04 x
group::r--
group:Users:rwx
mask:rwx


Ubuntu:

 > ls -l x; getfacl x
-rw-r--r-- 1 xubuntu xubuntu 0 Feb  9 15:04 x
group::r--

 > setfacl -m group:adm:rwx x
 > ls -l x; getfacl x
-rw-rwxr--+ 1 xubuntu xubuntu 0 Feb  9 15:04 x
group::r--
group:adm:rwx
mask:rwx

 > chmod g-wx x
 > ls -l x; getfacl x
-rw-r--r--+ 1 xubuntu xubuntu 0 Feb  9 15:04 x
group::r--
group:adm:rwx                   #effective:r--
mask:r--


------
Thomas

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

Re: group permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4037 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: group permissions

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Here's the problem:  Windows doesn't support an ACL_MASK entry, nor
> anything even remotely resembling it.

Right.  And pretending that it does is doing more harm than good, IMHO.

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

Please note that that the typical user in a corporate environment has no
rights to do this on network shares and even if (s)he did, it would quite
often break things for other users and is certain to draw the ire of the
share administrators just as if you'd do the same thing via WIndows' own
tools.  So please do not do this by default, there are just too many scripts
that blindly use some chmod somewhere.

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

Same issue as above, except it would be more easily reversible.

If anybody feels really strongly about these issues, they can always mount
"noacl".  We'll just have to live with how Windows implements ACL otherwise.


Regards,
Achim,


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

Re: group permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

On Feb 10 11:48, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Here's the problem:  Windows doesn't support an ACL_MASK entry, nor
> > anything even remotely resembling it.
> 
> Right.  And pretending that it does is doing more harm than good, IMHO.
> 
> > 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.
> 
> Please note that that the typical user in a corporate environment has no
> rights to do this on network shares and even if (s)he did, it would quite
> often break things for other users and is certain to draw the ire of the
> share administrators just as if you'd do the same thing via WIndows' own
> tools.  So please do not do this by default, there are just too many scripts
> that blindly use some chmod somewhere.
> 
> > 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:
> 
> Same issue as above, except it would be more easily reversible.

The permissions to change the ACL are not overly relevant here.  The
reason is, if the user has no permissions to write the DACL, it won't be
able to chmod anyway.  So, whatever we do to implement ACL_MASK, it's ok
even in a corp env, because the user apparently has the right to change
the DACL and thus it doesn't matter.

> If anybody feels really strongly about these issues, they can always mount
> "noacl".  We'll just have to live with how Windows implements ACL otherwise.

True.  Noacl mounts are the way to go in case of what you describe,
having no perms to write the DACL, even if the files are owned by
the user.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: group permissions

[Thomas Wolff]

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.

------
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com


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

Re: group permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: group permissions

[Achim Gratz]

Thomas Wolff writes:
> 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”.

Again, if you want POSIX-only directory trees, remove all inheritable
ACL from the top of the tree before populating it:

$ cd tree
$ setfacl -k .
$ setfacl -b .

That works without any changes to Cygwins behaviour and (at least if you
do the equivalent of those operations with icacls for instance)
independently of whether or not you're using the latest Cygwin.
Removing the inherited ACL from an existing tree might salvage it as
long as all files have been created by Cygwin and no non-inherited ACL
have been set deeper down, but you better check the state of things
first.  Something along the lines of

$ find . -print0 | xargs -0 getfacl > /tmp/perms
$ edit /tmp/perms
$ setfacl -f /tmp/perms ...

might be the safest route to accomplish this task, although for some
things icacls has some good options (like removing some or all ACL
associated with a specific SID recursively).  Unfortunately setfacl
cannot read the output of getfacl directly as a script, otherwise this
would be a doddle, but scripting a bit of a parser around it is quite
possible (I haven't needed to do it yet, otherwise I would post it).

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

That's not how Windows works its file systems and if you rub it the
wrong way you can easily make a tree unwriteable, unreadable or both.
That's actually one reason we aren't allowed to modify ACL on most our
network shares anymore, the IT support staff just got fed up recovering
botched ACL all day.  Also, there aren't any "Windows directory
defaults" that you could distinguish from "other default entries", so
that is getting nowhere.

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

Chmod shouldn't modify any ACL entries, "hidden" or not.  It doesn't do
that on Linux either, save for the mask bits which likely have been
added just for the purpose of keeping the illusion of permission bits
intact and that are explicitly for chmod to modify.  Since Windows
doesn't have mask bits, that functionality simply isn't there.

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

The only common case I know of is ssh, and it's a good thing that it
complains about other folks being able to read your key files.  It's an
easy fix as well.

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

If you want to ignore existing ACL then mount the tree "noacl".  Partial
ignorance is still ignorance and Cygwin shouldn't lie to the user unless
it is explicitly asked to do so.

I've been running with the AD/ACL enabled snapshots for quite some time
now and there hasn't been anything unfixable so far.  I still keep some
shares mounted with "noacl" since I just can't be bothered to properly
deal with them, but so far I haven't run into a real showstopper.  Yes
it's different than before, but in many ways better.  Get used to it
some time before you ask for hacks.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

Re: group permissions

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On 02/10/2015 02:21 AM, Corinna Vinschen wrote:
> 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.

Possible enhancement on this idea (I have no clue if it would actually
work, though):

When rewriting ACE entries because of the just-added restrictive
ACL_MASK, put in some marker that mimics the default deny-all action,
then additional entries in the tail of the ACE list that shows the
pre-modified permissions that we just took away due to the mask.  If we
later loosen the mask, we can use the tail of entries to restore
original permissions.  And since the tail occurs after a catch-all deny,
they won't grant permissions in the meantime.  The trick then becomes
telling when we have stuck our marker in place to represent that we have
injected tail entries to reflect the state to restore if ACL_MASK is
relaxed.

> 
> I'm open to discuss this further.  It needs implementing, of course.

Always the case, and sadly, my lack of experience in this topic is
showing through.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: group permissions

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

On Feb 11 13:28, Eric Blake wrote:
> On 02/10/2015 02:21 AM, Corinna Vinschen wrote:
> > 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.
> 
> Possible enhancement on this idea (I have no clue if it would actually
> work, though):
> 
> When rewriting ACE entries because of the just-added restrictive
> ACL_MASK, put in some marker that mimics the default deny-all action,
> then additional entries in the tail of the ACE list that shows the
> pre-modified permissions that we just took away due to the mask.  If we
> later loosen the mask, we can use the tail of entries to restore
> original permissions.  And since the tail occurs after a catch-all deny,
> they won't grant permissions in the meantime.  The trick then becomes
> telling when we have stuck our marker in place to represent that we have
> injected tail entries to reflect the state to restore if ACL_MASK is
> relaxed.

I see what you're up to.  Right now I'm just a bit side-tracked because
I had an inspiration how it should be possible to avoid the reported
"slow startup" problem due to slow LDAP conncetions to the DC.  After
that I'll return to the matter and peruse your idea.

In the meantime I also realized that the way Cygwin reads and creates
the file ACLs in two different sets of functions (one for stat/chmod,
the other for acl(GETACl)/acl(SETACL)) is a rather bad idea.

I think I'll take the opportunity to revamp the ACL handling completely
to unify the calls into a single implementation with consistent results.
Ideally the result is more POSIXy than today.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]