[Top][All Lists]

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

Re: Task startup

From: Niels Möller
Subject: Re: Task startup
Date: 27 Jan 2004 11:09:21 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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

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.


reply via email to

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