On Wed, Jun 30, 2021 at 12:12:28AM -0400, Theodore Ts'o 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? Its in "man xattr". David already copied pasted the relevant section in another email, so I am not doing it. > How file systems store and account > for space used by extended attributes is a file-system specific > question, > but presumably any way that xattr's on regular files are > accounted could also be used for xattr's on special files. That will be nice. I don't know enough about quota, but I am wondering why quota limits can't be enforced (if needed) for symlinks and special file xattrs. Thanks Vivek > > Also, xattr's are limited to 32k, so it's not like users can evade > _that_ much quota space, at least not without it being pretty painful. > (Assuming that quota is even enabled, which most of the time, it > isn't.) > > - Ted > > P.S. I'll note that if ext4's ea_in_inode is enabled, for large > xattr's, if you have 2 million files that all have the same 12k > windows SID stored as an xattr, ext4 will store that xattr only once. > Those two million files might be owned by different uids, so we made > an explicit design choice not to worry about accounting for the quota > for said 12k xattr value. After all, if you can save the space and > access cost of 2M * 12k if each file had to store its own copy of that > xattr, perhaps not including it in the quota calculation isn't that > bad. :-) > > We also don't account for the disk space used by symbolic links (since > sometimes they can be stored in the inode as fast symlinks, and > sometimes they might consume a data block). But again, that's a file > system specific implementation question. >
