Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2006-04-21 at 15:30 +0200, Jan Engelhardt wrote:
> >> >> Well then, have a look at http://alphagate.hopto.org/multiadm/
> >> >
> >> >hmm on first sight that seems to be basically an extension to the
> >> >existing capability() code... rather than a 'real' LSM module. Am I
> >> >missing something here?
> >> 
> >> (So what's the definition for a "real" LSM module?)
> >
> >No idea, try submitting the patch :)
> >
> Because it's too big, you only get URLs:
> 
> [01/02] http://alphagate.hopto.org/multiadm/mtadm_hooks-2.6.17-rc2.diff  137KB
> [02/02] http://alphagate.hopto.org/multiadm/mtadm_module-2.6.17-rc2.diff  27KB

For proper submission, you should split it up, e.g. one patch per new
hook you need and then your module.

The bulk of the first patch appears to be capable -> capable_x changes.
What is the purpose of that?

The set_task_ioprio hook looks legitimate; should be submitted
separately, modulo CodingStyle issues.

What's the rationale for the int->gid_t and int->uid_t changes in sys?

Some of the hooks used to exist in LSM patches but didn't have a real
user for merging at the time.  But it isn't clear whether you actually
need separate hooks for each of them or if they are being mapped to the
same check in many cases - can it be abstracted to a common hook?

Seems like you are duplicating a lot of the base DAC logic in the
process; would be nice to encapsulate that in the core kernel, and then
just use a common helper in both cases?

> Don't mention CodingStyle, I know. This is just a post to respond to the
> topic on why noone submitted it earlier.
> I already see it coming...

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/