Elad Efrat wrote:

First, thanks for the excellent summary.
quoted text
>
>    - For people who are interested in the finer-grained securelevel
>      knobs, this is somewhat more complicated.
>
>      By changing the meaning of securelevel, a third-party LKM no longer
>      has anything to refer to as a "system security level". I offer two
>      possible solutions:
>
>      (a) The securelevel variable will be maintained as "third-party LKM
>          securelevel", maintained only for backwards binary
>          compatibility. It will have no meaning in the NetBSD kernel,
>          but will retain the raise-only property of the current
>          securelevel.
>
>      (b) Third-party LKMs will be encouraged to remove references to
>          securelevel and use the kauth(9) interface, possibly with the
>          operation they want guarded from the list of common operations
>          for the system scope.
>   

Offer both of these solutions, and everyone should be happy. :-)  Even
better, item "a" should generate a warning message if possible.  (Maybe
if we ever get a true kernel loader, it could look for references to
securelevel and issue a warning.  Until we have a real kernel loader,
this might not be realistic.  :-)

We can announce eventual removal of securelevel as a variable at all,
but I think it makes sense to have a full release cycle in the middle to
allow folks with 3rd party code to adapt.

Btw, I would prefer not to have kauth be conditionally defined.  If
we're going to switch, we should just bite the bullet.    One question
that should probably be answered first would be to compare the size of a
kernel with kauth and without on some "size sensitive" machines: i386,
vax, and mips.  If the difference is minimal, then there is no point in
having a conditional, IMO.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191