Quoting Chris Wright ([email protected]):
> * [email protected] ([email protected]) wrote:
> > > James had suggested to effectively stash the list in the last slot, so
> > > there's only the array with one reserved slot.
> >
> > Oh, I didn't catch that. I like it. Will do.
> >
> > So you mean 3 slots total including the shared one?
>
> Yeah, i.e. common case is $LSM and capabilities. Stack slot is last
> one, and gets put to use only if needed.
>
> > Any comments on the added argument to register_security and
> > mod_reg_security to request a static slot?
>
> Why would you not request a static slot?
Capability wouldn't use it, though, so that slot would be wasted. In my
patch, capability, cap_stack, and root_plug don't ask for a slot.
> > + spin_lock(&security_field_spinlock);
> > + if (idx && *idx) {
> > + int i;
> > +
> > + *idx = -1;
>
> So, I guess this means you request one, but who knows which one you'll
> get?
If you get -1 back, you didn't get a static slot. But you don't have to
care as a module writer, the security_*_value functions will default to
using the shared slot if idx==-1.
> > + for (i=0; i<CONFIG_SECURITY_STACKER_NUMFIELDS; i++) {
> > + if (security_field_owners[i] == NULL) {
> > + security_field_owners[i] = ops;
> > + *idx = i;
This (idx != -1) means you got a static slot.
Of course this can now switch to idx==num_slots meaning you use the
shared slot.
> > Given the likelyhood of
> > capability/cap_stack being registered, it seemed worthwhile not to have
> > it waste a spot, but it is an API change...
>
> API change is no big deal. Seems useful to get index value so you can
> do optimized retrieve later. But, I don't see it useful to request that
> way. Just register, get index, if index == last slot, lookup hits list.
If we do switch to all LSMs getting a slot, should we just have the
return value for register_security and mod_reg_security be the slot#, or
-error?
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |