YAMAMOTO Takashi wrote:

quoted text
> 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?

The thread that took place ~2 months ago, "The reason for securelevel",
discusses *exactly* that: letting you do what you want, and others do
what they want. Nor once did I suggest both on the previous and this
threads that this is to completely replace securelevel. It's merely
reimplementing it to allow every person *choose* their own model.

quoted text
> 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.

quoted text
> 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?

quoted text
> 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.

quoted text
> are you suggesting to leave it as securelevel variable check for now?
> or to put it into a temporary scope for now?

I will repeat myself once again, by saying that if we *do* do it, it
will be done right. Leaving a securelevel check beats the purpose. What
I meant was having it in a temporary scope.

quoted text
> 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.

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

quoted text
> "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.

-e.

-- 
Elad Efrat