* Tony Jones (tonyj@private) wrote: > On Wed, May 25, 2005 at 08:10:47PM -0400, James Morris wrote: > > > Note: out of tree kernel code does not count for anything. It's not > > really part of the Linux kernel. Mainline maintainers don't care about it > > and should not be expected to. > > If I recall correctly LSM was created precisely because Linus didn't care > about security and didn't want to. In the context of this I don't understand > most of the above. Well, there are two (nearly orthogonal) points. 1) kernel development favors in-tree code over out-of-tree code, always. 2) LSM is there because Linus got requests from various projects to be _the_ advanced access control project in mainline Linux. His rule of thumb is to push back on the people who care to come up with a solution when there's competing interests. So it's not really a question of who wants to maintain it. Code in mainline comes with a maintainer (the submitter). The bonus to being in mainline is that code will be taken into account as api's evolve (which is always happening). > > As for choice, your LSM module is not in the mainline kernel, so only > > users of your particular kernel really get that choice. Why does LSM then > > need to be in the upstream kernel? Why not just keep it in yours, to > > support your out of tree security module. Why impose the burdens and > > limitations of LSM on the upstream kernel. > > a) Is LSM as it's currently defined a burden and limitation on the upstream > kernel? Serious question. I'm curious if it is actually viewed this way. I > can see that the interface doesn't let you easily do what you'd like (it > doesn't for us either) and that changes you would like expose a potential > additional burden and thus get rejected but this isn't the same thing. No, I don't see it as a burden at all. > b) LSM exists in the kernel to support a variety of modules which _users_ can > choose to load on their stock 2.6 kernel as they see fit. It is of > course hard to form any lucid argument once it's been decided that > maintainers are the only ones who count. No, there's two different maintainers involved here. One maintains some core subsystem, another maintains some user of that subsystem. What's at issue here is that maintainers of out-of-tree code typically get much less sympathy from maintainers of in-tree core code. In other words, infrastructure is not created to support out-of-tree users.
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 22:56:41 PDT