Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

[Vasily Kulikov <segoon@openwall.com>]

On Mon, Jan 07, 2013 at 20:11 -0800, Casey Schaufler wrote:
> On 1/7/2013 7:59 PM, Stephen Rothwell wrote:
> > You probably also want to think a bit harder about the order of the
> > patches - you should introduce new APIs before you use them and remove
> > calls to functions before you remove the functions.
> >
> The unfortunate reality is that I couldn't find a good way to stage the
> changes. It's a wonking big set of infrastructure change. I could introduce
> the security blob abstraction separately but that is a fraction of the
> change. If it would have gone through mail filters as a single patch I'd
> have sent it that way.
> 
> I can spend time on patch presentation, and will if necessary.

I guess it can be divided this way:

1) Introduce lsm_get_cred(), etc. which unconditionally return
->security, ->i_security, etc.

2) Move all LSMs, procfs, etc. to the new API, a patch per LSM/subsystem.

3) Change structures along with new API.


The pro of the division is that if you have a bug in the series (and you
surely have! ;)) it is MUCH more simple to locate this bug (bisect, etc.).
Also it is more descriptive as you divide LSM changes and the core security
subsystem itself targeted on multiple LSMs which divides LSM
implementations (which might be not very important for someone) and the core
architecture (which is important for everybody).

Thanks,

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments