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.
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".
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..
Yes, but I'm not sure these are "misc. operations"..
I'll give you two examples of operations: the first, is checking if
process A can "look into" process B. We use this check for things like
filtering ps and netstat output per-user. The second operation is "can
this process attach systrace to init". Obviously, this is a process
related operation, because the very act of attaching systrace (or
ptrace, for that matter) belongs -- clearly -- in the process scope.
However, I was suggesting a different point of view: there *is* a
difference between these two operations, the difference that justified
the creation of securelevel. While the first operation can cause little
harm to the system (so what if joeblow gets to see root owned
processes?), the second operation suggests that joeblow (or a
compromised root) could attach to init, manipulating it, compromising
the TCB.
This could very easily start an endless discussion. There is no right
answer for this one, I'm afraid. On one hand, we can have the
securelevel-related operations scattered across several scopes, possibly
even handled by different listeners (by playing with "defer"), where we
have to pay extra attention not to treat these as just operations that
are handled by, say, the generic or process scopes, but rather as
operations that if handled incorrectly can compromise the entire
machine.
Or, we could keep them all in one place, biting the bullet and preaching
on the mantra that "although they may be related to packet filter rules,
LKMs, or attaching to init", they all have the same common property of
being able to modify the TCB of the host -- and all are related to
either securelevel or (if we decide to implement) runlevel.
To be completely honest -- I don't think that *technically* it matters
what we choose to do. We'll get it right either way, I am just
presenting both sides of the coin.
It would be nice if other people voiced in on this matter so we can
move forward. :)
See above...
Can I assume that's an "okay" for the proposal, then? :)
That's not a valid suggestion, I think, because securelevel (or, the
traditional BSD securelevel model) does not care for "suser" or not.
It is. :)
-e.
--
Elad Efrat
