[...] > Along those lines, I think that the answer for ruid=0 > needs take into account > ACL entries, too. For instance (on Solaris 10 ufs > (POSIX draft ACLs)), a > file with ACL > > # file: testing > # owner: rlhamil > # group: sys > user::--- > user:uucp:--x #effective:--x > group::--- #effective:--- > mask:rwx > other:--- > > _is_ executable by root, because of the execute bit > for the additional > ACL entry. > > But on zfs, with it's more elaborate ACLs, a similar > file with an ACL > > 0:user:uucp:execute:allow > 1:owner@:read_data/write_data/append_data/execute:deny > > 2:owner@:write_xattr/write_attributes/write_acl/write_ > owner:allow > 3:group@:read_data/write_data/append_data/execute:deny > > 4:group@::allow > 5:everyone@:read_data/write_data/append_data/write_xat > tr/execute/write_attributes/write_acl/write_owner:deny > > 6:everyone@:read_xattr/read_attributes/read_acl/synchr > onize:allow > > is _not_ executable by root. Is that behavior > _supposed_ to be inconsistent > between the two ACL schemes? > > (In both cases, after creating the file, I did a > chmod 0 filename on it, > and then added execute access for user uucp using > either setfacl or chmod, > as appropriate.)
The inconsistency between the two ACL schemes is apparently worse than that. Since NFSv4 ACLs are usually said to be a superset of POSIX draft ACLs, I did the following: cp -p ufsdir/testing zfsdir/testing2 which should have "promoted" the ACL compatibly. The resulting ACL looked like: 0:owner@:read_attributes/write_attributes/read_acl/write_acl/synchronize:allow 1:owner@:read_dta/write_data/append_data/execute:deny 2:user:uucp:write_attributes/write_acl:deny 3:user:uucp:execute/read_attributes/read_acl/synchronize:allow 4:user:uucp:read_data/write_data/append_data/write_attributes/write_acl:deny 5:gr...@write_attributes/write_acl:deny 6:group@:read_attributes/read_acl/synchronize:allow 7:group@:read_data/write_data/append_data/execute/write_attributes/write_acl:deny 8:everyone@:read_attributes/read_acl/synchronize:allow 9:everyone@:read_data/write_data/append_data/execute/write_attributes/write_acl:deny and was also _not_ executable by root. Now, I guess it's a question of going back to the draft standard or standard to determine if they have anything to say about this discrepancy. Anyone have pointers to them (or better, has anyone with experience at that sort of thing taken a look at them regarding root execute access)? -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
