Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> On Wed, May 21, 2003 at 04:27:24PM +0200, Niels Möller wrote:
> > Who will be talking to who, in the suid case?
> > 
> > 1. Old task calls file_exec on the file server.
> > 
> > 2. File server calls task_create in the task server [...]
> > 
> >    Note that the new task gets the file server's accounting id.
> 
> Good point (I thought of that earlier and forgot it again).  Is this what we
> want?  I think that even for suid applications, you want to account this
> with the user who started the programm, and not the user who provides the
> filesystem.  I am unsure, though, as this is a border case.

I think that in principle, we want the task to be accounted with the
old user task at all times (so that a user can SIGKILL the process
even in the middle of a suid exec).

However, if it is accounted with the filesystem during startup, for a
short time, and changes to the user before it starts executing the any
in the loaded image, that may be good enough.

The main reason I don't want the user task to create the task, is that
then the fileserver has to ensure that the user task didn't leave any
code or boobytraps in it. That seems a little hairy. And then it
requires a task port abstraction (the task server gets simpler if we
can get by without that: I'd prefer that the task server not know
about object handles, because it implements task references which is a
building block for handles).

If it is important to get the right accounting from the start, I think
it's cleaner to pass the old tasks pid handle to the fs. Then the
filesystem can cooperate with task and proc to get it right from the
start (task needs a privileged call that creates a task with a given
accounting_id, and proc needs a call that takes a pid and invokes that
call. Task considers proc (but no other task) as privileged). But that
also seems pretty complex.

> > 4. New task returns a startup-handle to the file server (or the handle
> >    the fileserver has could be reused).
> 
> I am not sure we want handles at this point, but we will probably just use
> simple thread ids and send messages from one thread to another (and only
> that thread is allowed to).  OTOH, moving handles is required anyway, so it
> might not be more work to do it correctly.

Sure, if it helps, one can use raw thread ids instead of handles. But
as one needs to keep task references around anyway, that is almost the
same thing as a handle. The old and new task must communicate, and
then the old task needs to get references to each other in one way or
the other.

> > 5. File server passes the handle on back to the old task (and this is
> >    the end of the file_exec rpc).

> This is what I called a "complicated upcall" above.  The server can only
> move the handle to the old task by sending it a message and waiting until
> the old task received and accepted the handle (otherwise there is a race
> against the server releasing the handle).  This is what I want to avoid by
> creating the task in the old task and passing it down.

I think I see the problem. Perhaps one can tweak this, as the fs has
full control over the new task. I don't remember the exact protocol
for handle transfer, but what is needed is:

 * The new task should get a reference to the old task, and record
   that the task is allowed to communicate with it. (Involves file
   system, new task and the task server, so I think this should be
   easy).

 * The old task should get the thread id of the new task, and a
   reference to it. This is the hard part, it seems.

/Niels