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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/30/2023 7:28 AM, 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.
>
>> 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?
>
>> 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.

Which LSM(s) do you think ought to be deprecated? I only see one that I
might consider a candidate. As for weird behavior, that's what LSMs are
for, and the really weird ones proposed (e.g. pathname character set limitations)
(and excepting for BPF, of course) haven't gotten far.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux