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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |