> On Tue, 2004-06-29 at 09:35, Serge E. Hallyn wrote: > > I do plan on attempting the following steps to ease stacking: > > > > 1. submit a patch to allow multiple LSM's to use the kernel object security > > pointers, such as inode->i_security. This won't fly before 2.7, and will > > likely meet a lot of resistance. (Though it might help if there are people > > speaking up when I'm shot down :) > > > > 2. submit a generalized version of the stacker LSM (hopefully without the > > blob_stacking.c part, since part 1 will achieve this) to be kept in the > > kernel tree as another LSM. > > Why not just use a common blob header and chain multiple security blobs > on the existing security field, as suggested previously on this list? > That will require adjusting those modules that want to support such > stacking, but that is not unreasonable. My proposal (basically bsd's implementation) would also require adjusting existing modules. My concerns with your approach: 1. We might be adding many kmalloc's. It is certainly not the case that every security blob assignment leads to a kmalloc. Often it just leads to a copy of an already allocated structure. Now a kmalloc would always be required. 2. The difference in aesthetics and readability between directly using inode->i_security[my_index] and always walking/tweaking linked lists is imo pretty great. 3. Performance concerns have already been mentioned, I see. However it is a nice non-invasive (kernel-wise) solution. I will do some performance tests between the two approaches, hopefully with three modules. I hope to do this during july. thanks, -serge
This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 07:26:56 PDT