[ On Thursday, April 15, 1999 at 00:58:16 (-0700), Gandhi woulda smacked you wrote: ]
> Subject: Thought for the day...
>
> In case nobody's clued in, it's a call to set the real/effective
> user/group id of a process while it's running.
> 
> "But that's what set-id bits are for!"  I agree in the model we
> currently have.

Exactly.  Set-id is designed to go through the filesystem because that's
the best way to ensure integrity of the code that it is about to be
given new privileges.  That's also why most modern systems have been
fixed so that writing to a set-id file turns off the set-id bits unless
the writer is (already) the super-user.

With your proposed scheme you may as well just make /bin/sh set-id to
the target user and/or group and be done with it because sooner or later
someone will foil your "privilege broker" into giving away privs to a
piece of un-trustworthy code that'll just run /bin/sh anyway.  ;-)

If you can come up with some scheme where the privilege broker can
reliably get an fstat() of the open "text" file for the target process
and can ensure that the process' text segment is unwritable, then
perhaps you'd be a little safer, but I'm not really sure what this buys
you.  The broker can just as easily make available a setuid binary to do
the same thing.  If you've got processes that have to change privileges
so fast that they'd be hindered by exec()ing a set-id binary then I
think you've got a more basic design problem with your application.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>