YAMAMOTO Takashi wrote:

> to avoid making existing code insecure when introducing new scopes.

Let's say we introduced a new scope. Can you think of any situation
where we would dispatch authorization requests on this scope without
also adding some listeners? usually, the very requests we add to kauth.h
are the ones checked in the listener.

Adding a new scope, dispatching authorization requests for it in
critical parts of the kernel, and adding no listeners for it, and
managing for that to be out in a release (and not current) is a risk
we'll have to take; if we manage *that* then we have far more serious
problems to deal with.

>> Loading a listener changes the security model. Having no listeners means
>> that you can't really do anything the scope manages. Having an "always
>> block" policy is unacceptable.
> 
> why unacceptable?

Because I previously pointed out cases where this behavior will screw
one of the purposes of kauth(9) - pluggable security models - which
may not be shipped by us and compiled in.

>> I think making the behavior optional is
>> best. I don't care what would be the default behavior. :)
> 
> let's try to avoid introducing too many options.

This is not the place to save on options; see "IPFILTER_DEFAULT_BLOCK"..

-e.

-- 
Elad Efrat