>> 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
reason,
>> 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,
#if STACKER
extern void * stackerGet(void *secdata, char *ID);
#else
#define stackerGet(x, ID) (x)
#endif
isec = stackerGet(inode->i_security, ID);
Mimi
This archive was generated by hypermail 2.1.3 : Fri Oct 29 2004 - 09:13:17 PDT