On Sat, Nov 04, 2000 at 05:34:13AM +1100, matthew green wrote:
>    
>    Linux has the concept of setting the userid for file system operations 
>    only.  That too would solve this problem, since you'd be running with
>    the creditials of the original user to do the open, and then all the
>    problems just go away.  It doesn't matter if the user is playing games 
>    or not, they aren't doing it with elevated privs.
>    
>    It seems like less of a kludge than the solutions that have been
>    takled about here.  It still seems like a kludge to me, however.
> 
> 
> 
> this is the only solution i really can stomach, and it's taken me 3 years
> to get to that point...

I think the right solutions are either capabilities or "open_as".  I 
really, really don't like the idea of implementing zillions of 
special-purpose "uid"s.

Generally speaking, file-descriptor passing is a solution to this kind of
problem.  Unfortunately, it is difficult to persuade others to rewrite 
their code to use it.

There seems to be a general perception that FD passing is useful only
if/when you have a long-running daemon that doles out descriptors as
required, and that this leads to a plethora of long-running daemons that
become mandatory to run certain other programs.  That's not really true.
A nice mechanism is to have programs that used to be setuid become setgid;
they can then exec tiny setuid programs that are executable only by the
appropriate group, which can then pass them back the descriptors they need.
This technique is simple, elegant, and has the benefit that it completely
isolates all code that runs with root privileges, so it's much easier to
verify.

Note that I've moved this discussion to tech-security/tech-kern as it
seems more appropriate there.

Thor