Re: version of thread ids

[Marcus Brinkmann]

On Tue, May 20, 2003 at 11:05:15PM +0200, Niels Möller wrote:
> 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.

Right.
 
> 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?

There is a difference between an object handle wrapped into an fd and a
stray object handle that is lost and not accounted for anymore.  The first
one is just an extra object the suid app can deal with, the other is a
potential resource leak or DoS attack.

A suid application that doesn't want the inherited file handles can always
close them explicitely.  And glibc will close them automatically when the
program terminates.  I think this is what POSIX has to say on this issue,
and the same on any Unix system.

However, some caution might be advisable.  One difference is that an object
handle can be much more than a file handle in Unix.

> > 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.

Well, that is clear enough.  There is a lot of state that needs to be
inherited, and the fds are just a part of it.  In the
with-exec-server-model, this is guaranteed by first copying or moving
references to the exec server.  (Something I am not fond of either :)

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/