----- Original Message ----- From: "Greg KH" <gregat_private> To: "Demetrios Lambrou" <dlambrouat_private> Cc: <linux-security-moduleat_private> Sent: Tuesday, October 01, 2002 5:38 PM Subject: Re: Last question on rm -f unused_hooks* > 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. > There are two arguments against this position. One is that the whole reason for LSM was to provide a general framework for Linux security modules, so that people do not continually have to patch the kernel. So having hooks that are well-justified in those terms make sense, even if they may not be in use right now. The other is that some of the hooks are not in use right now, but people (like me) have said that we will use them. So taking them out seems less than helpful. We have a released product including a patched kernel and a GPL security module using hooks installed by the kernel patch. We are working on a second release, and are _right now_ working on porting it to LSM. Our LSM module will be GPL. We need the module hooks and we need to know about all mounts and unmounts, so it's not going to help us if those hooks are taken out. > 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, > please do. > LSM is a collaborative activity, and should be based on consensus, so I have trouble with you saying 'my decision'. Others do not agree with you, so you ought not to be making changes unilaterally. > > 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 > statement? > > > 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! > I have already spoken up, and am doing so again now. I need those module hooks! Mike _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Oct 04 2002 - 02:03:34 PDT