This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


Corinna Vinschen writes:
> Right.  It's a compromise.  I take it you don't like the extra behaviour
> for SYSTEM/Admins.  Neither do I.  Others are desperately waiting for
> more.  The problem with compromises is, they are usually best if nobody
> is completely satisfied ;)

I have argued against treating them differently, purely based on
consistency between the Windows and POSIX world (where possible at all).
Other considerations have prevailed (maybe rightly so), so I'm not too
surprised to find some inconsistency in the results.

> As I said before, this behaviour is not necessarily the last word.
> We have to see how this works out.  The point you're making here
> is certainly a point against this implementation.  But I'm willing
> to defend it to get more testing.

It probably works out OK for non-administrative users and prevents the
need for them to deal with Windows defaults they can't change anyway, so
that's a positive.  The problems when working with administrative rights
have just shifted to a slightly different place, but it seems you still
have to employ the same workarounds.

>> > 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.
> Uh, not quite.  POSIX defines
>    If any access permissions are checked, each shall be checked
>    individually, as described in XBD File Access Permissions , except
>    that where that description refers to execute permission for a
>    process with appropriate privileges, an implementation may indicate
>    success for X_OK even if execute permission is not granted to any
>    user.

I don't think you'll find a UN*X system that reports executable
permission on a plain file simply because root accesses it (for a
directory it would do that of course).  The situation in the above case
is on the face of it different (the ACL actually has the executable bit
set), but as I understand you've been wanting to treat both secondaries
like the root account.  I think it would be more sensible to ignore that
execute permission on plain files when otherwise none is granted (since
chmod will never mask it).  That would eliminate another reason to
entirely remove the default/inherited ACL and I don't think it has any
consequences on the Windows side.

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

SD adaptation for Waldorf rackAttack V1.04R1:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]