According to Thor Lancelot Simon:
>
>I think the right solutions are either capabilities

Hmmm capabilities is a big paradigm shift, that would take some
serious work.

> or "open_as".
>

For the folks at home that are trying to follow what this is about
here is some context:

before this thread moved here there was a proposal made to add another
syscall to the kernel that performed the same functions as open but
allowed the caller to pass a uid/gid pair as additional parameters.
The idea being that setuid programs could safely perform an open as
the uid/gid of the process that ran the setuid program thereby
preventing an elevation of privileges.  The implementation would be in
the kernel which prevents the common race conditions from happening
and the call would be restricted to root.

>  I 
>really, really don't like the idea of implementing zillions of 
>special-purpose "uid"s.
>

Not zillions.  If I understand it correctly you can just say "this is
the uid we will open files as", if this is the case then this may be a
bit limiting as you may want to open some files as root.

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

But it does lead to a proliferation of setuid programs which, in
itself, is not good.  If someone can get into the right group then
they will then have a nice array of setuid programs that will give
them all sorts of access.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================