Subject: Re: CVS commit: src/sys/kern
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 09/11/2006 14:21:47
> > 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.
> >> 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 don't think it is a good reason to make it per-scope.
> >> 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"..
- i don't think it's so relevant.
- i don't think IPFILTER_DEFAULT_BLOCK option is a great idea.
- iirc, ipfilter has a global knob to enable it.
it's basically what i suggested here.