Re: [PATCH] shmem: add support for user extended attributes

[Hugh Dickins]

On Mon, 14 Aug 2023, Snaipe wrote:

> > Your sending this patch does help to raise the priority for my
> > sending that patch: thank you; but I cannot promise when that will be.
> 
> Hey Hugh,
> 
> Just as an additional data point, if it helps with priority :)
> 
> The lack of support of user xattrs on tmpfs our last remaining blocker for
> using unprivileged overlayfs mounts that use a tmpfs for the upper dir & work
> dir. Not that it isn't possible to use unprivileged overlayfs mounts in general,
> but not having this option means that use-cases for discardable upper layer
> changes are harder to clean up correctly when not on an tmpfs mount whose
> lifetime is bound to a mount namespace.
> 
> I don't think there's any rush; we can live with rmdir failing with EIO for now,
> but it'd be great to see this fixed rather than having to implement expensive
> cleanup routines that have to remove the upper+work dirs recursively with
> CAP_DAC_OVERRIDE.

Thanks for the encouragement.  At the time that I wrote that (20 July)
I did not expect to get around to it for months.  But there happens to
have been various VFS-involving works going on in mm/shmem.c recently,
targeting v6.6: which caused me to rearrange priorities, and join the
party with tmpfs user xattrs, see

https://lore.kernel.org/linux-fsdevel/e92a4d33-f97-7c84-95ad-4fed8e84608c@xxxxxxxxxx/

Which Christian Brauner quickly put into his vfs.git (vfs.tmpfs branch):
so unless something goes horribly wrong, you can expect them in v6.6.

There's a lot that you wrote above which I have no understanding of
whatsoever (why would user xattrs stop rmdir failing?? it's okay, don't
try to educate me, I don't need to know, I'm just glad if they help you).

Though your mention of "unprivileged" does make me shiver a little:
Christian will understand the implications when I do not, but I wonder
if my effort to limit the memory usage of user xattrs to "inode space"
can be be undermined by unprivileged mounts with unlimited (or default,
that's bad enough) nr_inodes.

If so, that won't endanger the tmpfs user xattrs implementation, since
the problem would already go beyond those: can an unprivileged mount of
tmpfs allow its user to gobble up much more memory than is good for the
rest of the system?

Hugh