On Wed, 10 Feb 2010, Jason King wrote: > I suspect that zfs is interpreting the group ACLs and adjusting the mode > value accordingly to try to indicate the 'preserve owner/group on new > file' semantics with the old permissions, however it sounds like it's not > a symmetric operation -- if chgrp sees a directory with suid or sgid set, > it does chown(file, original_mode & ~(S_IFMT)), when it should probably > be more careful if ACLs are present.
The non-access control parts of the mode bits (suid/sgid et al) aren't part of the acl (and can't be represented by one), I haven't looked at the internal details, but even though zfs is a "pure acl" filesystem those bits are presumably stored differently. In an implementation like I'm looking for, where legacy chmod is either ignored or denied for access control, manipulating the other parts would still need to work. In this case, it's not even like chgrp is trying to remove the sgid bit. It's redundantly adding it when it's already there. I've opened a bug; while I haven't gotten a response yet I'm guessing they'll eventually fix it. Which is fine for that specific instance of the general "unexpected chmod assassinates acl, film at 11" problem, it doesn't address all of the other unknown problems not yet noticed. The only way to effectively address undesirable acl destruction by chmod is at the filesystem level, by allowing the user to disable it. > I do think the default aclmode and aclinherit settings are unintuitive > and quite surprising (I'd almost argue flat out wrong). I actually wouldn't necessarily agree; the defaults are geared towards making zfs behave like a typical unix filesystem, preserving POSIX compliance and making sure legacy apps work as expected. That's fine as a default, but the ability to make zfs actually functional as a pure acl environment should be available as an option. > I've found setting aclmode and aclinherit to passthrough saves what > little hair I have left. If you haven't tried that already, might want > to see if that helps any. I did that from day 1 :)... I'm happy at this point with aclinherit (barring one minor tweak to passthrough-x that's already had an approved fasttrack and is just waiting for opensolaris 3/10 to get released and the gate reopened for changes), if I could just get some aclmode enhancements I think we'd be set. > My experience (perhaps others will have different experiences) is that > due to the added complexity and administrative overhead, ACLs are used > when it's absolutely necessary -- i.e. you have something that due to > it's nature must have very explicit and precise access control. NFSv4 ACL's are ridiculously overcomplicated for the end user; but that's what pretty web gui's are for ;). We actually have one of those, allowing end users to easily control access to their files, and it would be working great, other than that every time I turn around the ACL's are broken by something or another :(. > The last thing I want is the system going behind my back and silently > modifying the permissions I'm trying to set, and leaving directories and > files with permissions other than what was set (which is what you get > today with the defaults). Ditto. I put that acl there for a reason, and I don't want anything trying to treat it like legacy mode bits. zfs is a great filesystem, and the CIFS compatible NFSv4 ACL's provide great potential for cross platform interoperability, but despite being a pure acl filesystem I don't think there's any feasible way at this point to allow access via NFSv4 or local shell and not break acl's one way or another. -- 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
