Messages in this thread | | | From | Bill Huey <> | Subject | Re: Some very thought-provoking ideas about OS architecture. | Date | 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/
| |