On Wed, 25 May 2005, Tony Jones wrote: > On Wed, May 25, 2005 at 09:32:31PM -0400, James Morris wrote: > > > It's a burden in that it needs to be taken into account by several core > > and other kernel maintainers when they modify the kernel or review patches > > which modify the kernel. If SELinux is to be the only user, then it's > > difficult to justify the continued presence of the LSM code. > > But the LSM hooks aren't going to just dissapear. Under what you propose they > will be replaced by other SELinux specific calls. How does this change the > impact to core/other kernel maintainers when they make changes? They are > still going to be faced with making changes near call points whose purpose > they may not be overly familiar with. That's a good point. Yes, the SELinux specific calls would still be there. The differences for cor maintainers would be: a) Clearer semantics, i.e. being able to trace the flow directly into the SELinux code and be able to see exactly what's happening. b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many, but not a large amount). I'd imagine that (a) would generally be seen now as a good thing, compared to the case of no other in-tree LSM users. > Are you saying that the issue is the lack of availability of source for > the LSM module? You've already said that as far as they are concerned > SELinux is the only LSM module that matters and it's source is intree. It's not about availability, it's about whether the code is part of mainline. What's in mainline is the kernel. Out of tree kernel modules are not part of the kernel. Possibly there's some confusion because Linux does not have any real kernel APIs (in the way that proprietary kernels do). It's a completely different model. The only guaranteed kernel interface is the syscall layer. - James -- James Morris <jmorris@private>
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 19:13:46 PDT