Re: Task startup

[Marcus Brinkmann]

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.

Thanks,
Marcus


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