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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfpegsUbvMB_tFbV283_JmK+wzFAECaLZgYAbmcBbBxWX=Ctw@mail.gmail.com>
Date: Tue, 14 Jan 2025 16:32:14 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: David Howells <dhowells@...hat.com>
Cc: mszeredi@...hat.com, linux-unionfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: How to support directory opacity in a filesystem for overlayfs to use?

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