Re: [PATCH -next 0/2] lsm: Change inode_setattr() to take struct

[Mickaël Salaün]

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.