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