On Tue, 14 Jan 2025 at 16:56, David Howells <dhowells@xxxxxxxxxx> wrote:
>
> Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> > On Tue, 14 Jan 2025 at 16:15, David Howells <dhowells@xxxxxxxxxx> wrote:
> >
> > > What's the best way for a network filesystem to make a native
> > > directory-is-opaque flag available to the system? Is it best to catch
> > > setxattr/getxattr/removexattr("overlay.opaque") and translate these into the
> > > RPCs to wrangle the flag?
> >
> > I don't know. Out of curiosity, which filesystem is it?
>
> One of the varieties of AFS. Unfortunately, xattrs aren't a thing and can't
> easily be added because of the volume transfer and backup protocols and
> formats.
>
> > There's "trusted.overlay.opaque" and "user.overlay.opaque" and are
> > used in different scenarios. There was also talk of making the
> > "trusted." namespace nest inside user namespaces, but apparently it's
> > not so important.
> >
> > Which one would you like to emulate?
>
> Um - I don't know the difference to answer that question.
"trusted." needs CAP_SYS_ADMIN in the init user ns, while "user."
needs write access on the object, which for an overlayfs mount in a
user namespace practically means CAP_DAC_OVERRIDE in the user ns.
So for plain, privileged overlayfs you'd want to implement
"trusted.overlay.opaque". I don't have a better idea, than to add the
xattr callbacks to the filesystem and return -EOPNOTSUPP for
everything else.
Thanks,
Miklos
