Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
what about SCREEN? library.linode.com/linux-tools/utilities/screen –  Hex Jan 21 '13 at 23:43
    
how would screen apply to this case? –  hoju Jan 22 '13 at 8:52

4 Answers 4

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.
share|improve this answer
    
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 8: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 8: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 9:17
  1. Setuid on the executables run by users A/B to user C.

  2. ?

  3. Profit

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.