Re: Some very thought-provoking ideas about OS architecture.

Bill Huey (billh@mag.ucsd.edu)
Tue, 22 Jun 1999 14:55:37 -0700 (PDT)

> Before you jump on this, consider that the all of the file I/O calls in UNIX
> area actually capability invocations. So is the open() call: open() implicitly
> references either the current root descriptor or the CWD descriptor, both of
> which are part of the process state. If you want to have a discussion in
> UNIX-centric terms, I'm arguing that *all* system calls should rely on some
> descriptor in this way, and that it should be well-defined what happens when the
> descriptor is void.
>
> For example, the whole notion of controlling signal delivery on the basis of
> parent/child trees is a bad idea. A better design would have explicit
> per-process descriptors, and give authority to signal based on whether the
> signaller held the appropriate descriptor. Such a design *can* support the
> current semantics, but is not limited to the current semantics.

Basically, from what I've read it translates to having a unified single delivery,
per syscall capabilities system that's not scatter-brainded hack spread out in the
Linux kernel now, right ?

You basically get all this simple and elegant encapsulation in one architectural
effort, right ?

With processes and signals as the exceptions ?

> Ultimately, I'ld note that when you strip away the syntax transformations you
> discover that above the vnode boundary UNIX is a capability system, with the
> notable exception of the signalling and process control mechanisms, which are
> rather crufty. With the introduction of /proc, processes have been given
> descriptors as well. What we now need to do is find a way to eliminate the
> legacy interfaces that render principled security in UNIX so difficult.

Uh, what you're saying is that the vnode/VFS interface is identical in structure
to Eros capabilities, but it not treated in uniform manner ?

bill

> Jonathan S. Shapiro, Ph. D.
> IBM T.J. Watson Research Center

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/