Re: version of thread ids

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> Now it is clear that the exec server needs to allocate a new task id for a
> secure exec and kill the old tasks, as it does now.

It took me a while before I understood why you don't want to keep the
same task id, just as you keep the pid. But this is almost clear now:
It's because that's the only way to purge all old object handles, as
the task could have a lot of random handles that no server involved in
the exec is aware of.

Consider this: The old process has an object handle to some server.
For some reason, it wants to make sure that the handle survives after
a setuid exec.

Then all the process needs to do is to wrap the handle inside an fd,
make sure the close-on-exec flag is clear, and exec the target setuid
file.

Can the process do any harm (which it couldn't do directly, without
using the setuid binary) by that trick? Does it matter if the new
setuid code gets the random object handle wrapped in an fd or not, and why?

> So now we use a completely new task object (in fact it is sufficient
> to just change the version ID and let the task server mark the old
> task id as dead [incl notifications and everything], there is no
> need to recreate the address space), and that will work out ok.

Ok, so at least this is a simple operation. But you also need to make
sure that handles associated with non-close-on-exec fd:s are
transferred to the new task.

/Niels