hi,

> > i don't think splitting securelevel is a good way to achieve
> > fine-grained control.  (see below)
> 
> But this is a discussion we *already had* and is not the subject of the
> thread. What *you* think is irrelevant, because *you* are given the
> choice to use whatever interface you want -- be it a single knob, or
> multiple knobs.

sorry again, can you privide a pointer?
do you mean, has it already been decided to split securelevel into
multiple knobs?  even if so, it's orthogonal to kauth.
i understand there are people who want multiple knobs,
but i don't understand why it should be done by splitting securelevel.

> We've been through that before. My initial post started with saying
> something "as we agreed that some people *do* want it, here is how
> everyone can be happy".

and not everyone seems happy.

> > TN mentions KAUTH_VNODE_WRITE_SECURITY/KAUTH_VNODE_NOIMMUTABLE, which
> > is what we want, i guess.
> 
> The vnode scope is what Mac OS X uses to take the permission checks out
> of each file-system specific code and into the VFS layer. We are not
> implementing it just yet, so this is out of the question.
> 
> Since this is a single case, IF we do decide to implement what I
> suggested, and WHEN we get around to have extended attributes working,
> and IF we decide to have the vnode scope handle the permission/ACL
> checks all in one place, and WHEN we get around to implementing that
> too, I promise you that I'll take care of that bit. :)
> 
> But for now... let's not let *that* be the show-stopper..

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

> > anyway, we need to factor out a set of operations/scopes necessary for
> > suser and securelevel.  ie. non trivial work :)
> 
> Can I assume that's an "okay" for the proposal, then? :)

if "the proposal" means your original "system scope" proprosal, no.

> > maybe you can use ISSUSER-like temporary placeholder for some aspects of
> > securelevel which don't have approrpriate scopes for now.
> 
> That's not a valid suggestion, I think, because securelevel (or, the
> traditional BSD securelevel model) does not care for "suser" or not.

i said ISSUSER-like.  not ISSUSER, of course.

> > i'm not sure if it's much better than direct manipulation of
> > securelevel variable, tho.
> 
> It is. :)

"it" here is "ISSUSER-like temporary placeholder" solution, right?

YAMAMOTO Takashi