[RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE
Dr. David Alan Gilbert
dgilbert at redhat.com
Wed Jun 30 15:01:42 UTC 2021
* Theodore Ts'o (tytso at mit.edu) wrote:
> On Wed, Jun 30, 2021 at 09:07:56AM +0100, Dr. David Alan Gilbert wrote:
> > * Theodore Ts'o (tytso at mit.edu) wrote:
> > > On Tue, Jun 29, 2021 at 04:28:24PM -0400, Daniel Walsh wrote:
> > > > All this conversation is great, and I look forward to a better solution, but
> > > > if we go back to the patch, it was to fix an issue where the kernel is
> > > > requiring CAP_SYS_ADMIN for writing user Xattrs on link files and other
> > > > special files.
> > > >
> > > > The documented reason for this is to prevent the users from using XATTRS to
> > > > avoid quota.
> > >
> > > Huh? Where is it so documented?
> > man xattr(7):
> > The file permission bits of regular files and directories are
> > interpreted differently from the file permission bits of special
> > files and symbolic links. For regular files and directories the
> > file permission bits define access to the file's contents,
> > while for device special files they define access to the device
> > described by the special file. The file permissions of symbolic
> > links are not used in access checks.
> All of this is true...
> > *** These differences would
> > allow users to consume filesystem resources in a way not
> > controllable by disk quotas for group or world writable special
> > files and directories.****
> Anyone with group write access to a regular file can append to the
> file, and the blocks written will be charged the owner of the file.
> So it's perfectly "controllable" by the quota system; if you have
> group write access to a file, you can charge against the user's quota.
> This is Working As Intended.
> And the creation of device special files take the umask into account,
> just like regular files, so if you have a umask that allows newly
> created files to be group writeable, the same issue would occur for
> regular files as device files. Given that most users have a umask of
> 0077 or 0022, this is generally Not A Problem.
> I think I see the issue which drove the above text, though, which is
> that Linux's syscall(2) is creating symlinks which do not take umask
> into account; that is, the permissions are always mode ST_IFLNK|0777.
> Hence, it might be that the right answer is to remove this fairly
> arbitrary restriction entirely, and change symlink(2) so that it
> creates files which respects the umask. Posix and SUS doesn't specify
> what the permissions are that are used, and historically (before the
> advent of xattrs) I suspect since it didn't matter, no one cared about
> whether or not umask was applied.
> Some people might object to such a change arguing that with
> pre-existing file systems where there are symlinks which
> world-writeable, this might cause people to be able to charge up to
> 32k (or whatever the maximum size of the xattr supported by the file
> system) for each symlink. However, (a) very few people actually use
> quotas, and this would only be an issue for those users, and (b) the
> amount of quota "abuse" that could be carried out this way is small
> enough that I'm not sure it matters.
Even if you fix symlinks, I don't think it fixes device nodes or
anything else where the permissions bitmap isn't purely used as the
permissions on the inode.
> - Ted
Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK
More information about the Linux-security-module-archive