> > sorry again, can you privide a pointer?
> 
> Are you serious? you already asked once on this thread for a pointer to
> an earlier discussion, and I gave it. If you read it, how are you asking
> for a "pointer" again?

i was not sure if you were referring to the same thread, so i asked.
i couldn't find any consensus about how to implement fine-grained control
in the thread.

> > do you mean, has it already been decided to split securelevel into
> > multiple knobs?  even if so, it's orthogonal to kauth.
> 
> Do you want me to repeat myself again?
> 
> The current code NetBSD uses has suser() checks, euid checks,
> and securelevel checks. I'm suggesting to get rid of that mess, and
> implementing securelevel using a kauth(9) interface is one step in
> that direction.

i don't have any objection to implementing securelevel via kauth.
however, i don't think splitting securelevel is really related to it.

> > i understand there are people who want multiple knobs,
> > but i don't understand why it should be done by splitting securelevel.
> 
> Then how are you intending on having the separation of knobs if all you
> have is a single raise-only integer?

you can have listeners for fine-grained knobs, in addition to securelevel
listener.
because the former is not a securelevel anymore, it's reasonable to
have separate listeners, IMO.

> > and not everyone seems happy.
> 
> If not everyone are happy, then I will simply not do what I suggest.
> 
> But I think you are wrong here too, because the discussion took itself
> to places like code size and performance and further enhancing what we
> have today by using run-levels, and was not tripped on "this is a bad
> idea". So saying "not everyone seems happy" is ignoring the fact that,
> at least as it seems to me, the *IDEA* of doing what I suggested was
> accepted, but people are interested on what implications it will have
> on size/performance etc.

at least i'm not happy, so "not everyone".

> > if "the proposal" means your original "system scope" proprosal, no.
> 
> Hardly. The proposal is to integrate securelevel and kauth(9) as the
> subject of this way-to-long thread suggests. The mail you are replying
> to also implies, probably not clearly enough, that I am so tired of
> these pointless arguments over tiny things that don't matter (this is
> wa beyond bikeshed) that if you keep insisting on implementing these
> knobs in their supposedly-appropriate scopes I'll just agree so we can,
> for once, move forward.

do you mean my comments were pointless?  sorry if so.

> I also asked that others comment on this issue as well so don't just
> have two opinions. That hasn't happened yet.

yes, let's wait for more opinions.

> > "it" here is "ISSUSER-like temporary placeholder" solution, right?
> 
> To keep on kauth(9) terminology, that is *not* "ISSUSER-like", but
> rather kauth_authorize_foo() calls.

i meant it's ISSUSER-like just in the sense that it's a temporary placeholder.


let me restate my opinions.

- handling securelevel via kauth is fine.

- in kauth world, securelevel should be implemented as listeners for
  appropriate scopes.

- if you want fine-grained control ("multiple knobs"),
  it should be another listener(s).  splitting securelevel is not a right way.
  (you might want to coalesce listeners to default one for performance.
  it's fine, but it doesn't change the logical structure, i think.)

- i'm not sure if securelevel is a good target to shoot now.
  it's better to tackle suser() first.

YAMAMOTO Takashi