> I wouldn't bother. I would still advise builtin, chaining, or some > hybrid of the two (then port SELinux to that approach for > testing/measurement). The hash table approach would be a step backwards > for LSM; I can see using it if we didn't already have per-object > security fields and couldn't get them accepted, but it makes little > sense given that we have them. 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. > 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 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? -serge
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 06:37:47 PDT