On Wed, 12 Oct 2005 19:43:30 -0700 Jun Inoue <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Oct 2005 15:38:10 -0400 > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > > I found Bas's note stunning, because I did not expect anyone to connect > > the dots about setuid vs. confinement so quickly. It is a point that > > usually requires several explanations. Indeed, setuid is not required at > > all in a capability system. The only thing that Bas missed is that if > > you have persistence you do not need a constructor server. > > Do you mean we can run a "constructor process" indefinitely as a > translator? For example if I compile a program foo, which needs my > capability bar, and make it accessible to everyone as /pub/jun/foo, I > would do: > > run-with-cap bar /pub/jun/foo-constructor > > Then I get a capability to an idle process, the foo constructor. Let's > call it P. I do: > > settrans --active --persistent /pub/jun/foo P > > Then P runs indefinitely as the active translator for node /pub/jun/foo. > Later, whenever someone types /pub/jun/foo, the process denoted by P > would spawn() the image (or fork() if foo-constructor contains an image > of foo), passing bar to it. Thus, /pub/jun/foo will effectively be > setcap'ed, without the need for a central server. > > But this scheme doesn't seem to leave room for others to verify > if /pub/jun/foo would leak additional capabilities given to it. How is > the verification done on EROS? Is it exact or conservative; ie can it > have false positives? Forget that question, I misunderstood what was being verified. Ensuring the inexistence of capabilities to suspicious channels is pretty straitforward. Only the inspection must be done by a trusted component. But that brings me back to your statement: constructor server is unnecessary if we have persistence...or, um wait, I'll shut up. Probably Bas meant exactly what I described by "constructor server". I guess I just made a fool out of myself here, sorry. -- Jun Inoue [EMAIL PROTECTED] _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
