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 > > http://marc.theaimsgroup.com/?l=linux-security-module&m=99980953709764&w=2 and http://marc.theaimsgroup.com/?l=linux-security-module&m=99986372711363&w=2. > > > > That should impose very little overhead on the single LSM case. > > Yes, I did. The results were posted at: > http://marc.theaimsgroup.com/?l=linux-security-module&m=109426300823429&w=2 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