On Tue, May 30, 2023 at 03:15:01PM -0700, Casey Schaufler wrote: > On 5/30/2023 9:01 AM, Christian Brauner wrote: > > On Tue, May 30, 2023 at 07:55:17AM -0700, Casey Schaufler wrote: > >> 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 > > I don't have a good insight into what LSMs are actively used or are > > effectively unused but I would be curious to hear what LSMs are > > considered actively used/maintained from the LSM maintainer's > > perspective. > > I'm not the LSM maintainer, but I've been working on the infrastructure > for quite some time. All the existing LSMs save one can readily be associated > with active systems, and the one that isn't is actively maintained. We have > not gotten into the habit of accepting LSMs upstream that don't have a real > world use. > > >> 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) > > If this is effectively saying that LSMs are licensed to step outside the > > rules of the subsystem they're a guest in then it seems unlikely > > subsystems will be very excited to let new LSM changes go in important > > codepaths going forward. In fact this seems like a good argument against > > it. > > This is an artifact of Linus' decision that security models should be > supported as add-on modules. On the one hand, all that a subsystem maintainer > needs to know about a security feature is what it needs in the way of hooks. > On the other hand, the subsystem maintainer loses control over what kinds of > things the security feature does with the available information. It's a > tension that we've had to deal with since the Orange Book days of the late > 1980's. The deal has always been: > > You can have your security feature if: > 1. If I turn it off it has no performance impact > 2. I don't have to do anything to maintain it > 3. It doesn't interfere with any other system behavior > 4. You'll leave me alone > > As a security developer from way back I would be delighted if maintainers of > other subsystems took an active interest in some of what we've been trying > to accomplish in the security space. If the VFS maintainers would like to > see the LSM interfaces for file systems changed I, for one, would like very > much to hear about what they'd prefer. What is important for us is that the security layer must understand and accept that some things cannot be done the way it envisions them to be done because it would involve design compromises in the fs layer that the fs maintainers are unwilling to make. The idea to pass struct path to almost every security hook is a good example. If the project is feature parity between inode and path based LSMs then it must be clear from the start that this won't be achieved at the cost of mixing up the layer where only dentries and inodes are relevant and the layer where struct paths are most relevant. > > We do a lot of crazy things to avoid interfering with the subsystems we > interact with. A closer developer relationship would be most welcome, so > long as it helps us achieve or goals. We get a lot of complaints about how > LSM feature perform, but no one wants to hear that a good deal of that comes > about because of what has to be done in support of 1, 2 and 3 above. Sometimes > we do stoopid things, but usually it's to avoid changes "outside our swim lane". I personally am not opposed to comment on patches but they will naturally have lower priority than other things. -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
