According to Thor Lancelot Simon:
>
>I think you rather seriously misunderstand,

Probably ;-)

>
>It is quite unlikely, using this approach, to end up with *more* setuid
>programs than you already had; the difference is that rather than having
>a large setuid program that anyone can run and that you have to trust to
>drop privs appropriately, or spend a lot of time analyzing, you have a
>small setuid program that can only be run by members of one group (which
>you don't actually put anyone in!) and only does one thing.
>

It's the "only does one thing" bit that made me assume there would be
a proliferation.  I think that where we differ here is that I believe
I can see cases where some setuid binaries may want to do a number of
things as root (e.g open a network socket, open a file) which, to me,
would mean a separate setuid binary for each function, no?

>You also appear to be laboring under the misconception that it would
>be advisable to use setgid to the _same group_ to protect access to
>the extracted setuid bits of our various setuid programs; this would
>seem to me to be rather obviously not the right idea.
>

Ah - ok.  In that case we will have zillions of groups to act as
containers for the setuid portions of a program.

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