On Mon, 2005-08-29 at 11:55 +0800, qiyong wrote: > Erik Mouw wrote: > >On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote: > >>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. > 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. > >>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. > 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)? 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 .... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/