Re: [RFC] [PATCH] Replace security fields with hashtable

From: Mimi Zohar (zohar@private)
Date: Fri Oct 29 2004 - 08:40:35 PDT

>> Personally,
>> I think it is really important to be able to share the hooks and the
>> associated
>> security data pointers in a logical and coherent fashion.  For this
>> it makes
>> sense to have stacker be the hook owner and all LSM security modules
>> writing to it.
>> None of the LSM security modules, other than perhaps Stacker, should be
>> builtin, but
>> should be loaded in the initrd.

>This makes sense iff you intend to use more than one module.  For the
>cases where you don't, it's pure overhead.  See the problem?

True, but what are the options?   Not providing support for sharing the
hook and data pointers, doesn't sound like a viable option.  So there are
two issues:  overhead and ease of coding for both with and without stacker.
To solve the ease of coding, we could define a Stacker API to access the
security field.  To solve the overhead issue, we could define a compile
time option indicating whether or not to use Stacker.  This option would
include a definition of the Stacker API to always return the security
field.  For example,

      extern void * stackerGet(void *secdata, char *ID);
#define stackerGet(x, ID) (x)

      isec = stackerGet(inode->i_security, ID);


This archive was generated by hypermail 2.1.3 : Fri Oct 29 2004 - 09:13:17 PDT