Re: Task startup

[Marcus Brinkmann]

On Thu, Jan 22, 2004 at 06:08:44PM +0100, Niels Möller wrote:
> But I think the number of capabilities that need to be listed in the
> startup page is *very* limited: There should be a reference to a
> parent task. The new task will have to talk to its parent to get
> copies of all other capabilities it needs or should inherit, using the
> handle transfer protocol. (For wortel modules, the wortel capability
> may be a special case).

Unfortunately it is not very limited at all, but it is a fixed number.
About 15 or so last time I counted.

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.  However, the suid application
also does not trust its real parent for things like root directory etc.  So
any information that the suid app must trust has to be provided by the
filesystem.  The filesystem wants to provide it up-front, put it into the
start page, and then forget about it forever.  This is why all the things
like auth cap, root and current dir cap, physmem cap, etc etc have
to be provided in the startup page.

Of course the startup page will also have a reference to the real parent.
Later on, the suid app will request all FDs etc from the real parent.
The relationship between the real parent and the child is very different
from the fielsystem and the child, so there we can use what you think of.

For simplicity, we can use the "complex startup page" also when we don't
have a suid page.  We can also use a simpler startup page in this case, if
it is an advantage.

> At least, that seems to be the simplest way to do it. Otherwise, if
> the new task should be given capabilities before the first thread is
> started, then we need a variant of the handle transfer protocol that
> lets the parent give away arbitrary capabilities to a task it
> controls, without cooperation from the receiving task (which hasn't
> got any thread running yet). I think that's possible, but I don't
> think it is necessary, and the handle transfer protocol seems complex
> enough without 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.

Of course this requires an initial thread in the started task.  The initial
thread will run on the initial startup page.  The startup page was never
meant to only contain data, it was always intended to carry a small
bootstrap program that does the part of the startup which can not be trusted
to the normal application's startup code (which is usually glibc's or the
linkers, but we can not rely on that).

> With the expectation that the startup code will contact the parent
> task to get additional information and capabilities, it's not
> necessary to but the command line arguments in the initial startup
> page, but it seems like a convenient thing to do. Simply because we'll
> anyway need *some* ipc with a grant item or string item to pass it
> over.

The command line args must be in the startup page if this is a requirement
for suid apps, and otherwise not.  It's that simple.  Everything that is
necessary in the suid case must be done in the startup code, anything else
can be punted to later, if it can.

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/