Re: group permissions

[Achim Gratz <Stromeko at nexgo dot de>]

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