On Fri, 26 Feb 2010, Nicolas Williams wrote:
> I believe we can do a bit better.
>
> A chmod that adds (see below) or removes one of r, w or x for owner is a
> simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
> modifying / replacing / adding owner@ ACEs (if there is one). A similar
> chmod that affecting group bits should probably apply to group@ ACEs. A
> similar chmod that affecting other should apply to any everyone@ ACEs.
I don't necessarily think that's better; and I believe that's approximately
the behavior you can already get with aclmode=passthrough.
If something is trying to change permissions on an object with a
non-trivial ACL using chmod, I think it's safe to assume that's not what
the original user who configured the ACL wants. At least, that would be
safe to assume if the user had explicitly configured the hypothetical
aclmode=deny or aclmode=ignore :).
Take, for example, a problem I'm currently having on Linux clients mounting
ZFS over NFSv4. Linux supports NFSv4, and even has a utility to manipulate
NFSv4 ACL's that works ok (but isn't nearly as nice as the ACL integrated
chmod command in Solaris). However, the default behavior of the linux cp
command is to try and copy the mode bits along with the file. So, I copy
a file into zfs over the NFSv4 mount from some local location. The file is
created and inherits the explicitly configured ACL from the parent
directory; the cp command then does a chmod() on it and the ACL is broken.
That's not what I want, I configured that inheritable ACL for a reason, and
I want it respected regardless of the permissions of the file in its
original location.
Another instance is an application that doesn't seem to trust creat() and
umask to do the right thing, after creating a file it explicitly chmod's it
to match the permissions it thinks it should have had based on the
requested mode and the current umask. If the file inherited an explicitly
specified non-trivial ACL, there's really nothing that can be done about
that chmod, other than ignore or deny it, that will result in the
permissions intended by the user who configured the ACL.
> For set-uid/gid and the sticky bits being set/cleared on non-directories
> chmod should not affect the ACL at all.
Agreed.
> For directories the sticky and setgid bits may require editing the
> inherittable ACEs of the ACL.
Sticky bit yes; in fact, as it affects permissions I think I'd lump that in
to the ignore/deny category. sgid on directory though? That doesn't
explicitly affect permission, it just potentially changes the group
ownership of new files/directories. I suppose that indirectly affects
permissions, as the implicit group@ ACE would be applied to a different
group, but that's probably the intention of the person setting the sgid
bit, and I don't think any actual ACL entry changes should occur from it.
> chmod(2) always takes an absolute mode. ZFS would have to reconstruct
> the relative change based on the previous mode...
Or perhaps some interface extension allowing relative changes to the
non-permission mode bits? For example, chown(2) allows you to specify -1
for either the user or group, meaning don't change that one. mode_t is
unsigned, so negative values won't work there, but there are a ton of
extra bits in an unsigned int not relevant to the mode, perhaps setting one
of them to signify only non permission related mode bits should be
manipulated:
chmod("foo", 012000) // turn on sgid bit
chmod("foo", 010000) // turn off sgid bit
chmod("foo", 014000) // turn on suid bit
chmod("foo", 010000) // turn off suid bit
> You should probably stop using the set-gid bit on directories and use
> inherttable ACLs instead...
Hmm, I suppose that could be implemented by using an explicit group: ACE
rather than the group@ ACE, but having the group ownership of the object
match and be expressed by group@ just seems a lot cleaner. ACL's don't get
rid of the concept of user and group ownership, and I don't think
the suid/sgid concept is going to get dropped anytime soon, so might as
well avail of it :).
But back to ACL/chmod; I don't think there's any way to map a permission
mode bits change via chmod to an ACL change that is guaranteed to be
acceptable to the creator of the ACL. I think there should be some form of
option available such that if an application is not ACL aware, it flat out
shouldn't be allowed to muck with permissions on an object with a
non-trivial ACL. In such a mode, only ACL operations should be allowed to
modify the permissions. They're really two separate security domains,
operations from one shouldn't be mixed with the other.
--
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
