Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7

[Achim Gratz <Stromeko@nexgo.de>]

Corinna Vinschen writes:
>> -rw-------+ 1 ASSI Kein 48880  5. Apr 2014  ucl.log
>> # file: ucl.log
>> # owner: ASSI
>> # group: Kein
>> user::rw-
>> group::---
>> group:SYSTEM:rwx                        #effective:---
>> group:Administratoren:rwx               #effective:---
>> mask:---
>> other:---
>> 
>> It seems that some of the code doesn't take the masking bits into
>> account just yet.  Here's the relevant portion of an strace on a
>> different file (I had already deleted the ACL on the original ones):
>
> What means "deleting the ACL"?  You always have an ACL in some way, no?
> What does getfacl and icacls print after the delete?

It means "setfacl -b" in this case.  Which removes the (inherited) ACL
for SYSTEM and Administrators.

> In theory, the access(2)/faccessat(2) functions should not rely at all
> on the new code.  The reason is that they are implemented using the
> underlying OS function to evaluate ACLs.  That means, they provide the
> actual access the OS grants.

That means they do not lie to the user like the mode bits do.  Which
breaks all sorts of assumptions that POSIX programs are allowed to make.
In turn one will almost universally have to remove the corresponding ACL
grants (the inherited ACL will always have rwx modes) when using an
administrator account (in this particular instance that's an easy thing
to do, luckily).  This kind of brings us back to where we started with
the discussion of whether to handle SYSTEM and Administrators specially,
only that the point of decision is now moved from mode check to
(f)access(at).  The outcome is the same: if you can't remove those ACL,
then correct POSIX semantics aren't possible.

> In the above case, SYSTEM and Administrators both have execute
> permissions, because they are never masked if they are secondary
> accounts, as outlined in the test release announcement.

A POSIX program trying to shortcut the ACL handling would conclude it
doesn't need to look beyond the mode bits.  A program that checks with
faccessat anyway gets told a different story.  The only analogue to this
is with root having implicit access to files on UN*X systems, but I
think "executable" would still be determined from the mode bits in this
case.

> So the result of access is the real thing, while the above output from
> getfacl is wrong.  My bad.  It should never print an "effective" value
> for SYSTEM and Administrators, but I forgot to handle them explicitely.
> I'll fix that.

Thanks.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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