On Fri, 26 Feb 2010, Nicolas Williams wrote: > 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.
You actually answered that in your previous email with option c. Ignore the ugo bits of the argument to chmod, and only process the suid/sgid/sticky bits. The filesystem does know the current mode bits when chmod is called, doesn't it? http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/sys/zfs_znode.h line 145, the zp_mode value in the znode_phys_t structure, labeled "file mode bits". At any given time, unless I'm mistaken, this value stores the legacy mode bits for an object, distinct from and separate of the ACL. It seems it would be fairly trivial to implement an aclmode which only applied the suid/sgid/sticky bit part of the argument to chmod and ignored the rest, leaving it as is. > 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. I think there is an option not to copy the mode bits. But it does by default, and I don't really want to try and get every person on campus who mounts their files via NFSv4 from a linux system to try and change the default behavior of a base utility. And they might even want that behavior on the local filesystem. > Such an app is broken. Yes it is. But even if I could fix it (assuming it's not a proprietary binary), there would be another one after it. And then another. And another. The only way to fully fix this issue for all possible instances of bad defaults or broken applications is for the filesystem itself to enforce it. > 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. No need; based on your other email and a little code digging I think the ignore option could be implemented entirely within the zfs code, allowing manipulation of suid/sgid without changing ugo bits, with no change in behavior or interface required by anything else. > 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.) My definition of an ACL-aware application is one that *never* tries to manipulate legacy mode bits on an object with a non-trivial ACL. Based on that definition, it's easy to tell :). And if an ACL aware application wants to play with mode bits, first it should use the ACL API to set a trivial ACL on the object, at which point chmod and mode bits would work fine. > 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). And I think you absolutely should be able to configure your fileserver to implement your preference. Why shouldn't I be able to configure my fileserver to implement mine :)? -- 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
