Subject: Re: Integrating securelevel and kauth(9)
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 03/27/2006 05:56:57
> > 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?