> >>> 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?
> > 
> > 3rd party listeners.
> 
> That's exactly what this was for: if we *don't* have it, you create
> a situation where, if the listeners are loaded via LKM during boot-time,
> their *loading* will be denied because the default rule says "no
> listeners, always deny". That's *exactly* why it needs to be
> configurable.

yes, i know.
my suggestion was to have a global knob for that, rather than per-scope ones.
see below.

> > i don't think it is a good reason to make it per-scope.
> 
> How is the code I did "per-scope"? it's in kauth_authorize_action().

kauth_authorize_action checks if the given scope has any listeners or not,
which is a per-scope status.

> > - iirc, ipfilter has a global knob to enable it.
> >   it's basically what i suggested here.
> 
> Again, isn't this what I was saying..?

no.  iiuc, yours is per-scope.

well, whether per-scope or global is not a fundamental point, actually.
essentially, my suggestion was to replace the following code
in kauth_authorize_action

	if (SIMPLEQ_EMPTY(&scope->listenq))
		return (0);

with

	if (listeners_have_not_been_initialized_yet())
		return (0);

listeners_have_not_been_initialized_yet() is a system global status.
in this way, once you have finished the initialization,
you can make "unknown" scopes all-deny by making the global flag false.

YAMAMOTO Takashi