Re: Task startup

[Niels Möller]

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?

After the transfer of capabilities from filesystem to the new task,
the new task will load some more code and start communicating with its
real parent. After that it's no longer trusted by the filesystem. The
new task can send a clear break up message like "I will no longer
serve you. From now on my real parent will be my true master. This is
the last message from me that you can ever trust", so that the file
system knows when the transition from trusted to untrusted occurs.

One may be able to replace some of the initial rounds of the
filesystem->new-task capability copying protocols by information
provided in the startup page, but to me that seems like a tweak, not
an essential requirement.

Regards,
/Niels