On Sep 2 21:42, Achim Gratz wrote: > Corinna Vinschen writes: > > More or less, just compare the ACLs and see if you find strange > > differences. This only works for the ACLs created or modified with > > `setfacl' and the snapshot DLL. > > I see, I'll have to make extra tests for this. Usually I just have to > live with some inherited ACL that I can't change at all. > > > The ACLs created or modified via > > setfacl with the older DLLs always were different and, I have to admit, > > kind of broke the default POSIX permissions created via open() or > > chmod(). The idea of my change was to make them always in an identical > > fashion. The order may only vary in secondary permissions, but never > > in the standard permissions, which also always come first. > > One thing I've noticed, but can't really say if it's related to the > change, is that setfacl quite often claims an "illegal ACL" when trying > to remove for instance the SYSTEM read permission.
$ setfacl -d g:system: filename Note the trailing colon. > Removing the group > owner ACL instead did the right thing in at least one instance. ??? It shouldn't. Removing the standard ACL entries for the owner, owner group, and other is not allowed: $ setfacl -d g:: filename setfacl: No error The "No error" is a bug, related to the fact that the aclsort() function doesn't set errno if aclcheck() failed. I just fixed that in CVS. > I've mostly been removing all ACL from the whole tree via the explorer > security tab (for ~/.ssh/ and similar stuff). *All* ACL??? That sounds wrong to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpFZzps41_Ga.pgp
Description: PGP signature
