How to support directory opacity in a filesystem for overlayfs to use?

How to support directory opacity in a filesystem for overlayfs to use?

[David Howells]

Hi Miklós,

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?

Thanks,
David

Re: How to support directory opacity in a filesystem for overlayfs to use?

[Miklos Szeredi]

On Tue, 14 Jan 2025 at 16:15, David Howells <dhowells@redhat.com> 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?

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?

Thanks,
Miklos

Re: How to support directory opacity in a filesystem for overlayfs to use?

[David Howells]

Miklos Szeredi <miklos@szeredi.hu> wrote:

> On Tue, 14 Jan 2025 at 16:15, David Howells <dhowells@redhat.com> 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.

David

Re: How to support directory opacity in a filesystem for overlayfs to use?

[Miklos Szeredi]

On Tue, 14 Jan 2025 at 16:56, David Howells <dhowells@redhat.com> wrote:
>
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> > On Tue, 14 Jan 2025 at 16:15, David Howells <dhowells@redhat.com> 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