Bernd Petrovitsch wrote:

On Mon, 2005-08-29 at 11:55 +0800, qiyong wrote:
 

quoted

Erik Mouw wrote:
   

quoted

On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote:
     

quoted

I just wrote a tool with kernel patch, which is to set the uid's of a running
process without FORK.

The tool is at http://users.freeforge.net/~coywolf/pub/promote/
Usage: promote <pid> [uid]

I once need such a tool to work together with my admin in order to tune my web
configuration.  I think it's quite convenient sometimes. 

The situations I can image are:

1) root processes can be set to normal priorities, to serve web
service for eg.
       

Most (if not all) web servers can be told to drop all privileges and
run as a normal user. If not, you can use selinux to create a policy
for such processes (IIRC that's what Fedora does).
     

In this way, it's that the web servers themselves drop the privileges, 
not forced by sysadmin.  sys_promote is a new approach different from 
   

The sysadmin selects the tool and writes the configuration file. So for
the purpose of this discussion, it is effectively the same.

 

quoted

selinux or sudo.  sys_promote is manipulating a already running process, 
while selinux or sudo is for the next launching process.
   

Kill the process and start it again. Problem solved.

 

quoted

quoted

quoted

2) admins promote trusted users, so they can do some system work without knowing
 the password

       

Use sudo for that, it allows even much finer grained control.
     

sudo may become a security problem.  Sysadmin and the user don't like 
   

(almost) every tool may become a security problem.
If you fear a bug in sudo, then write a minimal setuid wrapper for
yourself which checks for the user it started and exec's a binary (with
the full path name specified).
And even then - dependent on other details of the setup - you have the
gap of security problems (or misuse) because of holes in the security.
 

But if we make sure a tool doesn't introduce any new secrutiy problem, 
that's good enough.

quoted

the user's account
always have priorities.  My sysadmin Hommel says this to me:
   

What does the user do if the process terminates (for whatever reason)
and must be restarted by the user (manually or auutomatically)?
 

If we worry that, we'd make a persistent OS instead.

Basically I can see no need for "one time in history" actions. A daemon
can terminate and must be restarted (it may even be a software bug that
causes this and this doesn't change anything that the daemon's admin
must restart it *now*). The machine may reboot for whatever reason ....
 

The US space shuttle certainly can auto pilot, so it doesn't need a 
control panel.
And If anything fails, NASA  just launch another ship?