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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
