On 30/05/2023 16:28, Christoph Hellwig wrote:
On Tue, May 30, 2023 at 03:58:35PM +0200, Christian Brauner wrote:
The main concern which was expressed on other patchsets before is that
modifying inode operations to take struct path is not the way to go.
Passing struct path into individual filesystems is a clear layering
violation for most inode operations, sometimes downright not feasible,
and in general exposing struct vfsmount to filesystems is a hard no. At
least as far as I'm concerned.
Agreed. Passing struct path into random places is not how the VFS works.
I understand, it makes sense for the FS layer to not get access to
things not required. IIUC, the main issue is the layering, with LSM
calls being sometime at the last layer.
So the best way to achieve the landlock goal might be to add new hooks
What is "the landlock goal", and why does it matter?
Landlock's goal is to enable (unprivileged) users to set their own
access rights for their (ephemeral) processes (on top of the existing
access-controls of course) i.e., to sandbox applications. Landlock rules
are defined by users, and then according to the FS topology they see.
This means that Landlock relies on inodes and mount points to define and
enforce a policy.
or not. And we keep adding new LSMs without deprecating older ones (A
problem we also face in the fs layer.) and then they sit around but
still need to be taken into account when doing changes.
Yes, I'm really worried about th amount of LSMs we have, and the weird
things they do.
About Landlock, it's a new LSM that fit an actual need. I'd be glad to
hear about not recommended things and how to improve the situation. I
don't know all the history between VFS and LSM.
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs
