Grant permission to manage another users processes – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, permissions, process, , .
I have userA and userB who start processes:
userA@server:~$ ./some_command.sh &  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?
Process management is performed with a third party module so could not apply sudo without a significant rewrite.
Having users share a uid is a very frowned upon practice.
- Look into the
sudocommand. This is the goto solution for “how do I run a command as another user”: you specify entries in an
/etc/sudoersfile 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
sudoabtraction. (i.e. a role that allows a user to execute
sudo su - oracleto 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
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.
Setuid on the executables run by users A/B to user C.
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.
Probably best to use a proxy process under userA/userB reading control files for each PID.
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.