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

From: Stephen Smalley (sds@private)
Date: Wed Oct 27 2004 - 06:49:24 PDT

On Wed, 2004-10-27 at 09:37, Serge E. Hallyn wrote:
> I completely disagree (of course), and feel that the kernel should provide
> the interface for proper usage of the security fields.  This should not be
> done in an ad-hoc fashion.

An analogy for you:  would you recommend removing the i_uid field from
struct inode and instead maintaining a separate hash table mapping
inodes to i_uids?  I hope not.  The security fields belong in the kernel
objects.  Whether or not those security fields should be arrays, lists,
or whatever is another issue entirely.  I don't see how builtin or
chaining are ad-hoc.

> > Also, did you ever try the embedded header approach, as described in 
> > and
> > 
> > That should impose very little overhead on the single LSM case.
> Yes, I did.  The results were posted at:

Umm, no - that looks like you instead used the other approach of having
a separate data pointer in a common header rather than embedding the
common header in the security structure itself.  In any event, those
results seemed to fit well with James' suggestion of creating a hybrid.

> I would be far happier with the embedded header approach if we simply
> turned each ->security into a struct hlist_head.  How does this sound
> to people?

If you make it a pointer to a common header that contains the module id
and list pointer, and then embed that header in every security object,
then you get very little impact on the single LSM case.  Just making it
a list directly doesn't help, right?  

Stephen Smalley <sds@private>
National Security Agency

This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 06:53:19 PDT