> > > > > I see no reason for "access(file, X_OK))" > should return 0 for > > > > ordinary files which have no execute bit set. > > > > > > > > I think we can just change that. > > > > > >Modulo due diligence to see what in our codebase > might be depending on it. > > >Is it really worth it? > > > > As supposed to adding __posix_access or not > touching anything? > I was speaking specifically with regard to changing > the semantics of X_OK > for access(). I agree the existing behavior is > questionable but one could > make the argument that all of access() is a > questionable. If this issue > is e.g. impacting porting code from other systems > then I see the point. > Otherwise, why do this and risk unintended breakage?
Notwithstanding the disclaimer in the man page, this is likely to be something more often worked around (by examining st_mode from stat(2)) than depended on; indeed, it's hard to imagine why anything would depend on the historical behavior, or that something that coded around it would suddenly fail if that changed. A reasonable expectation is that access(2) simply answers the question "if my euid were set the same as my ruid, would I be allowed this access on this object (assuming its permissions didn't get changed in the mean time)?" Historically (with just Unix permission bits), root could execute a file if _any_ of the execute bits were set. 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_xattr/execute/write_attributes/write_acl/write_owner:deny 6:everyone@:read_xattr/read_attributes/read_acl/synchronize: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 only problem I see is that the current work-around (using stat(2)) behaves differently than the actual answer to the question "can root execute this?", because the former doesn't take into account the ACL. Thus, a change would either still fall short of expectations, or behave differently than the most obvious work-around. Either might prove surprising. And the apparent inconsistency between POSIX draft ACL behavior and NFSv4/ZFS ACL behavior regarding what marks a file that's executable by root may make this even more confusing (unless the latter is a bug...). -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
