> 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. Bad analogy - there is only one value for the i_uid field. > 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. I like the builtin approach, but noone else seemed to like it... When every module has to define similar, yet different, structures, and implement redundant logic for finding their own data, I consider that ad-hoc. However, it's possible that the chaining approach can be implemented nicer. IE if the security fields are made hlist_heads, and the requisite common header is laid out in security.h, like the sysfs fields. In the end, we might both be wrong about what the kernel maintainers might actually be willing to accept, which is why I was just trying several approaches. After/pending feedback from this list, I planned on sending two or three approaches to lkml. > > 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. Hmm, you're right, I didn't truly embed the header. I will try it that way. > Just making it > a list directly doesn't help, right? Could you elaborate on the last question? I don't understand what you mean... thanks, -serge
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 07:09:03 PDT