lkml.org 
[lkml]   [2005]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: syscall: sys_promote
Bernd Petrovitsch wrote:

>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.
>
>

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

>
>
>>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?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-29 10:19    [W:0.054 / U:4.760 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site