Jason Thorpe wrote:

> Right, specifically, do they need to worry about what security model is
> in use?  And how do they allocate a request # for their operation?

First, let's clarify terminology: an "action" is the top-level request,
such as KAUTH_NETWORK_SOCKET, for example. A "request" (or sub-action)
is in the form of KAUTH_REQ_<SCOPE>_<ACTION>_<REQUEST>.

The NetBSD kernel provides only the actions and requests for operations
in the NetBSD kernel. There are some "generic" combinations 3rd-party
LKMs can use (KAUTH_GENERIC_ISSUSER, also see some stuff in the network
scope IIRC).

If it can't be covered by any of the existing requests, it means that
the decision policy is also provided by the LKM. In that case, the LKM
is better off registering a new scope for its stuff.

If, however, we care about an LKM introducing actions on an existing
scope, we could probably write a per-scope allocator pretty easily. But
when do we have such a situation that can't be solved by adding a new
scope? going this route (allowing LKMs to allocate actions on existing
scopes) would have a requirement from security model developers to
properly handle "unknown" requests.

I'm not sure if we wanna go there yet...

-e.

-- 
Elad Efrat