[lkml]   [2021]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE
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.

> 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.

 \ /
  Last update: 2021-06-30 16:28    [W:0.066 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site