Daniel Carosone wrote:

> There would of course be room for refactoring and reorganising the
> model implementation (less cascading case statements and smaller
> funtions, maybe? whatever..), either within the bsd44 model or between
> it and future ones. 

Absolutely. Refactoring will happen both inside the security model
implementation and outside it -- some of these changes have already
gone in the tree, some are in the patch I posted online, and some
are still going through review.

> However, that can -- and should -- come later.
> Right now, the only impact this should have might be to consider space
> in the directory structure for a common library to be used from
> multiple models.  secmodel/common seems fine for that.
> 
> I predict, when the time comes, that people will start out developing
> new secmodels as "just like bsd44 apart from *this* little change",
> and it would be good to facilitate that style of granular overriding,
> rather than encouraging wholesale copy/paste of seclevel dirs. (making
> securelevel static to bsd44/securelevel.c, as the comments there
> indicate, might not be so easy or sensible in that context.)  But
> let's leave that till then.

This is one of the design goals, allowing new models to use existing
features; you can see securelevel, for example, can be used without
pulling in the superuser stuff and vice versa.

Moving stuff to a common/ directory is unnecessary; superuser
and securelevel are part of the 4.4BSD security model, and can be
pulled in from within it. 'securelevel' being static only indicates
that it can't be accessed or manipulated directly -- see how the
sysctl(9) handler is not static, for example.

However, I can see taking out handlers for the major scope actions
to their own functions, for example.. but like you said, that'll happen
later on.

-e.

-- 
Elad Efrat