YAMAMOTO Takashi wrote:

> you can always have a listener to check "costum knobs".

I'm not sure I follow. What would the listener check if there aren't
separate bits (or whatever) that indicate the different knobs?

> - "lkm" scope?
> - "vfs namespace" scope for mount/unmount/etc?
> - "machdep" scope?
> - "specfs" scope for kmem and raw device?
> - "immutable bit" thing should be a part of FILEOP or VNODE scope, maybe.
> - misc things might be a part of existing "generic" scope.
> 
> it might not be worth to have fine-grained scopes for
> slow operations like lkm and mount.

Some things that are worth saying here...

The vnode scope is used only for access control operations -- the
permission checks that are now part of the file-system code -- because
it's *very* heavily used. I suggest we trust Apple on this one and not
attempt to add more things to it.

As for the other scopes, you see what kind of mess is created here? we
introduce more scopes than actually necessary and over-complicate it.
I assume we'll end up placing knobs for the "lkm", "machdep", "specfs"
scopes and the misc. things in the generic scope. The fileop scope does
not seem right for things like handling the immutable (and other) bits,
so that'd probably go in generic as well.

The "machdep" scope is actually more of a i386/amd64/xen scope; don't
quote me on it but I think there is very minimal use -- if any -- of
securelevel in other MD code.

So... it might be the case that introducing a new scope that can be
called "system" (or, "TCB" :) to control the variety of knobs that might
affect the TCB be worthwhile, after all...

Of course, this is just my opinion, and I'd be more than happy if others
could comment on that matter as well.

> i don't think it's necessary to hurry up to create
> scopes for this purpose because there's no need to convert
> all securelevel checks at once.

This I don't agree with. As my original post on the thread said, there
are going to be two ways for handling the securelevel implications: the
"traditional" way and the "new" (multi-knobbed) way. If we change only
parts of the code, we're dragging feet.

> it might be better to create scopes necessary for things currently using
> suser first, and see if each aspects of securelevel fit into them,
> because the former is more primary user of kauth.

That's an excellent suggestion. The amount of converted-suser() calls in
the kernel is rather large, so if other developers are interested in
helping to identify what privilege is requested in each of them we can
achieve that faster.

I wouldn't want to think, however, that we'll hold with the securelevel
work because of it. A large amount of the work is changing the
references to securelevel to kauth(9) calls with the proper request,
and for that we don't need to wait until all converted-suser() calls
have more descriptive requests, IMHO. :)

-e.

-- 
Elad Efrat