[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Task startup

From: Marcus Brinkmann
Subject: Re: Task startup
Date: Tue, 27 Jan 2004 11:44:23 +0100
User-agent: Mutt/1.5.4i

On Tue, Jan 27, 2004 at 11:09:21AM +0100, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> > The reason is that we have strict requirements for suid applications.  They
> > must be started by the filesystem, but the filesystem does not trust them.
> > So, the filesystem can not act as the parent and go into a normal server
> > request loop until the child releases it.
> [...]
> > I don't see a problem here.  The startup page contains the information about
> > the caps, and the code to accept them.  The startup code is cooperating with
> > the filesystem, because the startup code is provided by the filesystem (in
> > the suid case).  So, the filesystem can transfer any caps by the normal
> > protocol into the new task, because the startup code is doing the receiver
> > side according to the protocol.
> This looks inconsistent. As far as I can see, the filesystem will
> task_revoke the new task (all this is about the setuid case), make
> sure that it is empty, map some code and data into it, and start an
> initial thread. So far, the filesystem should be able to ultimately
> trust the new task. So why can't it use the standard capability
> transfer protocols to copy things like the filesystem's root directory
> capability?

Oh, so you are saying that there doesn't need to be that much initial
information in the startup page, because this information can be part of a
message from the filesystem to the new task?

That is true, it might be very well possible.  That would make at least the
filesystem side look more vanilla.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]