Re: version of thread ids

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

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

The only way the setuid app can "deal" with the fd:s is to close them.
So if the user program has set up the setuid app to inherit fd 10, 11,
..., 4711 to refer to extra objects, and that is a problem, then the
setuid app have to loop over all fd:s (not entirely trivial, as
there's no MAX_FD) and close them. I would think that's *not*
recommended practice in any program, but I haven't written any setuid
programs.

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

The automatic close on exec happens automatically when the task exits.
I'm here considering the case where the task id and all task death
subscriptiptions survive the exec. So I don't think this is a problem.

I find the server process argument (object id:s reused after the exec
changes the meaning of old handles belonging to others) a more
compelling reason for retiring the old task id, even if it's more
about robustness than security.

/Niels