On Tue, 2 Mar 2010, Nicolas Williams wrote: > If no modebits were to apply to ACEs with subjects other than > owner@/group@/everyone@ (what about subjects that match the file's > owner/group but aren't owner@/gr...@?) then there'd be no way to use > modebits as a big filter for ACLs. This is why I proposed the above.
I'm not sure what you mean about using mode bits as a filter. Why would you want to use mode bits as a filter? I agree that for backwards compatibility, a read only view of the mode bits expressing as closely as possible the underlying ACL permissions is desirable; but when it comes to actually evaluating access to the object, the mode bits simply should not be involved. The ACL standing alone is sufficient to make a determination, why complicate/confuse it? As far as explicit user/group ACE's that happen to be for the same user/group as owns the object, there's a clear definition for how the ACL should be interpreted. From a semantic point of view, a user:fred ACE is identical to a user@ ACE if the owner is fred. There's no need to involve mode bits in the matter. > All reasons I have for it really come back to this: the idea of a primary > group and file group is an anachronism from back when ACLs (and > supplementary group memberships!) were overkill. Perhaps, but the concept of a "file owner" and "file group", along with the special ACE's, can still be useful, or at least used coherently. > The way to make the best of that situation is to give every user their > own private group. That's one possibility; basically equating user and user primary group as the same underlying authorization entity. Another possibility is what I do here; all users share the same primary group, basically equating user primary group with "has an account" (not necessarily the same as everyone@, as for some of access methods that would allow anyone in the world unauthenticated access to an object). I wouldn't necessarily say one or the other is "best", although my approach avoids 69,000+ extraneous groups in our deployment :). I still say that the only reason to give each user their own private group is because of the limitations of the umask/mode bits implementation, and if those limitations were removed, it doesn't make much sense anymore. > You have a good idea of what is "simple" for your use case. Your use case > also appears to be greatly influenced by what we could (should, do) > consider to be a bug in Samba. Obviously I'm biased towards my needs ;), although in pursuit of such I don't believe I am making any claims that are not factual. I'm not sure what Samba issue you are referring to. Are you referring to my inability to get it to not chmod stuff? If so, that issue is simply one instance of the underlying problem I am trying to address, its existence has no more or less influence to my goal than any other instance of the same underlying issue. I have not declared that a bug, nor have I asked Sun to do anything specifically about samba/chmod other than mentioning it as an example in my proposal for allowing ACL's to be chmod-free. Or are you referring to the bug in which membership in more than 32 active directory groups results in the setgroups() call failing in samba resulting in the user having no supplementary group list at all? That issue has nothing to do with ACL's or chmod and is completely orthogonal to this discussion. > Your idea of "simple" may not match every one else's. And your idea of > "simple" might well differ if that one application didn't use chmod() at > all. The fact that samba belongs to the class of applications that is impacted by acl/chmod interaction doesn't really change my proposal. I've actually fixed my samba problem, as I believe I previously mentioned I preloaded a shared library overloading chmod and making it a noop. If all I needed to do was fix samba I'd be done. But I'd like to address the entire class of applications with similar issues at the one and only point at which they can all be resolved at once -- the file system itself. > Personally I don't see a simple, non-surprising solution. I see a set of > solutions that one could pick from. And I'm not saying there is such a beast; only that the solution I'm proposing resolves one set of potential problems and should be seriously considered as one of the set of solutions made available. I've got nothing against other solutions available for other people with other problems, 50 different aclmodes is fine by me. Perhaps you don't recall, but I (only semi-jokingly) suggested the ability to specify an aclmode "script" to describe exactly how the interaction between chmod/mode bits/ACL's be implemented, allowing any conceivable solution to be implemented by anyone who needed it. > In all cases I think we need a way to synthesize modebits from ACLs > (e.g., for objects created via protocols that have no conception of > modebits but have a conception of ACLs) -- that's a difficult problem > because any algorithm for doing that will necessarily be lossy in many > cases. It's fairly easy to downconvert an ACL into mode bits, user@, group@, and everyone@ come pretty close. Making up a set of mode bits to feed to non-ACL-aware applications makes perfect sense. My problem is going the other way, trying to take a set of mode bits and somehow upscale it into an ACL is broken for my needs. Yes, some people might need that capability, and I absolutely support that they should have it -- but I'd like to have the capability to not have it. > > If you only ever access ZFS via CIFS from windows clients, you can have a > > pure ACL model. Why should access via local shell or NFSv4 be a poor > > stepchild and chained down with legacy semantics that make it exceedingly > > difficult to actually use ACL's for their intended purpose? > > I am certainly not advocating that. Good :). I am certainly not wedded to my proposal, if some other solution is proposed that would meet my requirements, great. However, pretty much all of the advice has boiled down to either "ACL's are broken, don't use them", or "why would you want to do *that*?", which isn't particularly useful. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
