On 5/31/2023 1:36 AM, Christian Brauner wrote: > 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. Yes, and that's completely acceptable. What would be really great is some guidance about what to do instead. Fishing for NAKs isn't fun for anybody. > 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. Which is a fair point, and helps those of us who don't work in the VFS layer daily understand the rationale. > >> 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. I can't say that I see how security features "naturally have lower priority", but everyone has to balance things. -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
