On Fri, Feb 26, 2010 at 04:26:43PM -0800, Paul B. Henson wrote: > 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 :).
Suppose you deny or ignore chmods. Well, how would you ever set or reset set-uid/gid and sticky bits? chmod(2) deals only in absolute modes, not relative changes, which means that in order to distinguish those bits from the rwx bits the filesystem would have to know the file's current mode bits in order to compare them to the new bits -- but this is hard (see my other e-mail in a new sub-thread). You'd have to remove the ACL then chmod; oof. > 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. Can you make that utility avoid the chmod? The mode bits should come from the open(2)/creat(2), and there should be no need to set them again after setting the ACL. > 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. Such an app is broken. > > For set-uid/gid and the sticky bits being set/cleared on non-directories > > chmod should not affect the ACL at all. > > Agreed. But see above, below. > > 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. I think both can be implemented as inherittable ACLs. > > 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? But we'd have to extend NFSv4 and get the extension adopted and deployed. There's no chance of such a change being made in a short period of time -- we're talking years. > 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: True, there's enough unused bits there that you could add ignore bits (and mode4 is an unsigned 32-bit integer in NFSv4 too), but once again you'd have to get clients and servers to understand this... > [...] > > 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. But is an application that sets an ACL and chmods ACL-aware? How can the filesystem tell? (Answer: it can't really, as it may not be able to relate the two operations.) As I wrote in that new sub-thread, I see no option that isn't surprising in some way. My preference would be for what I labeled as option (b). Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
