Grant permission to manage another users processes

Question

I have userA and userB who start processes:

userA@server:~$ ./some_command.sh &
[1] 30889

I then have a web app running as userC that manages those processes (suspending, resuming, terminating, and killing).

How can I give permission to userC to do this? For security I want to avoid giving userC root privilege.

I have complete control over userC. One possibility is changing the user ID to same as userA, but then what about userB?

Update: Process management is performed with a third party module so could not apply sudo without a significant rewrite.

what about SCREEN? http://library.linode.com/linux-tools/utilities/screen — Hex, Jan 21 '13 at 23:43

score 2 · Answer 1 · edited Apr 13 '17 at 12:14

Having users share a uid is a very frowned upon practice.

Suggestions:

Look into the sudo command. This is the goto solution for "how do I run a command as another user": you specify entries in an /etc/sudoers file that indicate which users (or groups, etc.) are allowed to run commands as different users, and under what circumstances. Its configuration can also be placed into a LDAP directory.
If this is a production environment (or something that you plan to eventually place in a production environment), it's considered best practice for userA / userB to be an "application user". This is an account with a name that easily conveys its intended purpose (oracle, webapps, etc.) and not one that any user considers "their" personal account. Ideally no one should be able to log in as this user (i.e. disabled password), and if you wish for users to obtain shell access to that user it should be done via sudo abtraction. (i.e. a role that allows a user to execute sudo su - oracle to obtain an oracle shell) This forces users to log in as themselves before becoming the application user and leaves a better audit trail.
If neither of these solutions are feasible, you may want to go with @Hex's suggestion of using a terminal multiplexer like screen or tmux, though some abstraction between login and shared application accounts is still recommended. You should try to avoid this unless the processes have terminal interaction of some sort.

userA / userB / etc are real user accounts where terminal processes are started. Then the internal web app helps manage certain processes. — hoju, Jan 22 '13 at 08:48
And the process management is performed by an existing third party library, so I don't see how sudo would be used. — hoju, Jan 22 '13 at 08:50
Write a script/program that makes the library calls, then invoke it via sudo in order to have the correct effective UID at execution time. If this is not feasible, please update the question with more details. Avoiding the sudo abstraction would require it to be setuid root, which is generally asking for it. — Andrew B, Jan 22 '13 at 09:17

score 1 · Answer 2 · answered Jan 23 '13 at 02:38

1

Setuid on the executables run by users A/B to user C.
?
Profit

answered Jan 23 '13 at 02:38

dmourati

24,720
2
40
69

score 0 · Answer 3 · edited Apr 13 '17 at 12:14

0

I would suggest a combination of Monit and sudo for job control...

Monit would handle the start/stop/status of the app.

Sudo with Monit rights would give you the collaboration aspect.

See: allow a user to run specific monit action

edited Apr 13 '17 at 12:14

Community

1

answered Jan 22 '13 at 00:00

ewwhite

194,921
91
434
799

score 0 · Answer 4 · answered Jan 22 '13 at 01:53

Probably best to use a proxy process under userA/userB reading control files for each PID.

some_command.sh:

thecommand &
CTL=/var/run/%1.ctl
echo %1 > $CTL
while read -n 1 cmd; do
    case $cmd in
        k)
            kill %1
            exit $?
            ;;
        s)
            kill -TSTP %1
            ;;
        ...
done < $CTL

You could have the worker processes reading the control files... but then they wouldn't continue, would they.

Grant permission to manage another users processes

4 Answers4