> > i meant, eg. you can write an listener like the following and
quoted text
> > register it to KAUTH_SCOPE_PROCESS scope, to replace securelevel checks
> > in sys_ptrace() and process_checkioperm().
> > 
> > 	int
> > 	securelevel_process_listener_callback(....)
> > 	{
> > 		switch () {
> > 		case KAUTH_PROCESS_CANPTRACE:
> > 		case KAUTH_PROCESS_CANIO:
> > 			if (p == initproc && securelevel > -1) {
> > 				return KAUTH_RESULT_DENY;
> > 			}
> > 		}
> > 		return KAUTH_RESULT_DEFER;
> > 	}
> 
> But you lose the ability to set custom knobs, as was already previously
> discussed... (because you have only one securelevel variable, and not
> where to store indication on which knobs are raised or not)

sorry, i think i missed the previous discussion.
can you give me a pointer to it?  was it in this thread?
i'm not sure what's "custom knobs".

quoted text
> Another consideration is that the number of listeners can directly
> affect the performance of an authorization request for a given scope.
> That said, we might want to add the "KAUTH_PROCESS_CANIO", for example,
> to the default listener for the process scope, instead of creating a new
> listener for securelevel-related operations.

maybe.
because coalescing listeners is merely an optimization,
it's better to postpone it until we measure performance impacts, i guess.

quoted text
> > for the case of "filter rule modification", you can write another listener for
> > the scope which covers the operation.
> > yes, you need to create an appropriate scope, i think.
> 
> Yes, a network scope.. and, as a side-note, I'm pretty sure we could use
> kauth(9) to do what pfil(9) is doing now, but this is a rather critical
> part that'll have to go under some serious performance tests if we ever
> think in that direction. :)

i'm pretty sure it's an abuse of the interface. :)

YAMAMOTO Takashi