On 01/21/2014 02:51 PM, Florian Weimer wrote:
To my knowledge, it is not possible to implement AT_EMPTY_PATH in
userspace in a race-free manner (even with the /proc/self/fd kludge), so
I'd like to add the for missing system calls.
I would like to pick up this again.
Here's an extended rationale for this functionality (which also applies
to fchmodat4):
I need a (relatively) race-free way to check that the link count of a
file is less than 2, followed by a setxattr operation on the file
handle. Ideally, the file has not been opened fully, to avoid open side
effects, so this suggests using O_PATH. But the current fsetxattr
implementation is not compatible with O_PATH. In the end, I want to
teach chmod -R/chown -R and various SELinux relabeling mechanisms not to
do stupid things when hard links are involved. For this application, it
doesn't matter if the inode grows another link between the check to
ensure it is less than 2 and the permissions update, as long as it
wasn't 2 or more from the start. We now have protected hard links, but
we still need to support running without them.
Based on off-list discussions, O_PATH support for the f*xattrat family
(and fchmod*) is not controversial in itself. But it's an open question
if we need new system calls, or if we can just reuse the existing f*
variants.
Arguments against just making the the f* variants work with O_PATH
descriptors are:
For fchmodat, POSIX requires that if the descriptor does not refer to a
directory, an ENOTDIR error is returned. (O_PATH is outside of POSIX,
so we might get away with ignoring this, but if we use O_PATH to
implement O_SEARCH, that would clearly be non-compliant. Whether that
matters is a different question). This wouldn't apply to fchmod. The
xattr functions aren't part of POSIX, so these concerns apply over there
only by analogy.
The other set of arguments are related to security concerns and
descriptor leaks, e.g. a SUID program applying changes through an O_PATH
descriptor which the invoking user could not have opened without O_PATH.
I tried to find something more concrete int his area, but failed.
However, POSIX seems to permit fchmod on file descriptors opened
read-only (and the kernel matches). If such misbehaving SUID programs
existed, they could be abused to corrupt /dev/null permissions even
without O_PATH. In short, this line of reasoning is a bit dubious.
All existing O_PATH accessors started as the f*at functions with
AT_EMPTY_PATH, but there has been some movement towards accepting O_PATH
descriptors in other places, see commits
9d05746e7b16d8565dddbe3200faa1e669d23bbf and
55815f70147dcfa3ead5738fd56d3574e2e3c1c2. But these are reading operations.
Comments?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
