|| ||Greg KH <email@example.com>|
|| ||Demetrios Lambrou <firstname.lastname@example.org>|
|| ||Re: Last question on rm -f unused_hooks*|
|| ||Tue, 1 Oct 2002 09:38:14 -0700|
On Tue, Oct 01, 2002 at 06:09:47AM -0400, Demetrios Lambrou wrote:
> So you are saying that frequent changes to the base kernel (once LSM becomes
> part of the mainstream kernel) are ok and that Linus would be happy to have
> new hooks added ,whenever there is a person that has a new LSM idea.
I do not speak for Linus, so I do not know.
> But he is not happy with the idea that there would be some hooks that
> are not used at the time of the merge. Maybe the LSM people should
> give it some more time before cutting out hooks.
I am not happy with the idea that there would be hooks in the kernel
that are not being used. That's not the Linux way. If the code isn't
being used, it's removed. I do not expect to ask anyone to try to
maintain the presence of a hook that is not being used.
And personally, I will not ask Linus to accept a patch for a hook that
is not being used. If you have a problem with my decision about this,
and think you can make a convincing argument to the upstream maintainer
of the specific piece of code where that hook lives, by all means,
> Why dont you keep it simple and stick to the original LSM design?
That sounds simple to me. And what design rules am I breaking with this
> If you really think that some hooks should not be there, publish a new
> paper called the "New LSM framework" and then change the framework.
Hm, a bit touchy aren't we? :)
Seriously, we are still mediating access to kernel objects, just like
the original design. I don't see how getting rid of the module_* hooks
means we have a "whole brand new LSM framework" to deal with.
> The original paper is getting a bit out of date now. The framework is
> drifting slowly from truly generic to 5 or so existing LSMs specific.
Patches gladly accepted. As all we have to work with is 5 or so
existing chunks of code that actually _use_ this framework, I don't know
what else we can use.
If you have a LSM module that needs one of the hooks that we are
proposing removing, speak up!
linux-security-module mailing list
to post comments)