On Tue, 29 Jun 2004, Serge E. Hallyn <hallyn@private> wrote:
> My proposal (basically bsd's implementation) would also require adjusting
> existing modules.
>
Is that the inode->i_security[my_index] way?
What about something like
/* manager internal lsm id, allocated on registration */
typedef uchar lsm_id;
struct sec_blob {
uchar num_entries;
lsm_id user1;
lsm_id user2;
lsm_id user3;
void *blob1;
void *blob2;
void *blob3;
};
On alloc, lsm's get to say whether they want to copy the existing value,
change it, or leave the slot empty. Any accesses need to go through a
manager function (taking some sort of id), which would be in a position to
implement copy on write, as well as expanding the blob array should need
arise.
Probably needs a refcounter to be added. One could make a separate 64-bit
version. Number of registered lsm's limited to 255 or so.
Comments?
The reason for this is of course that with lists, every lsm needs to alloc
a new blob for every object it attaches it to, as there is no way of
knowing when other lsm's might change their blobs, which could change the
link pointers. For arrays, one also needs to alloc one for every blobbed
object, with a limited size.
Are primary lsm's currently allowed to change the security field between
alloc and free? That would make limited arrays... limited in usefulness, as
a new lsm might want to add its blob to an already allocated array, risking
overflow.
What are the current usage (alloc & update) patterns for the blobs?
> I will do some performance tests between the two approaches, hopefully
> with three modules. I hope to do this during july.
>
Looking forward to that.
/Tomas (no need to keep Cc :))
This archive was generated by hypermail 2.1.3 : Wed Jul 07 2004 - 07:06:29 PDT