Re: [PATCH 0/3] Implement the f*xattrat family of functions

[Florian Weimer <fweimer@redhat.com>]

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