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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux