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

From: Stephen Smalley (sds@private)
Date: Wed Oct 27 2004 - 07:28:19 PDT


On Wed, 2004-10-27 at 10:08, Serge E. Hallyn wrote:
> Bad analogy - there is only one value for the i_uid field.

But it is part of the inode state, has the same lifecycle, etc.  Same as
the security field.  Separate hash table may make sense for loosely
associated data with differing lifecycles, not for the security field.

> > Just making it
> > a list directly doesn't help, right?  
> 
> Could you elaborate on the last question?  I don't understand what you
> mean...

If you define a common header in security.h and make the security fields
pointers to it rather than just void*, then you've defined a common
convention for all security modules to embed those headers in their own
security blobs, with those headers including both a module id and a list
pointer that can be accessed by any security module.  If you just make
it a list pointer, a given security module has no standard way of
vetting whether the referenced object is owned by it.
Right?  On the other hand, your suggestion is more flexible and allows a
LSM to avoid wasting space for the module id entirely if it so chooses,
so that may be preferred.

-- 
Stephen Smalley <sds@private>
National Security Agency



This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 07:32:09 PDT