* Theodore Ts'o (tytso@xxxxxxx) wrote: > On Wed, Jun 30, 2021 at 09:07:56AM +0100, Dr. David Alan Gilbert wrote: > > * Theodore Ts'o (tytso@xxxxxxx) 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. Dave > - Ted > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
