What's the canonical way to have an upstart job change its userid and run the script as an unprivileged user?
Obviously one can use
sudo, but this seems hacky (and can generate needless log lines).
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
How about using start-stop-daemon?
exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd
From Upstart cookbook:
The recommended method for Debian and Ubuntu systems is to use the helper utility
start-stop-daemondoes not impose PAM ("Pluggable Authentication Module") limits to the process it starts.
start-stop-daemon not supported in RHEL.
There are several ways to do it, all with slightly different semantics, particularly relating to group membership:
setuidgid will put you in the group you specify.
setuidgidwill put you only in that group, so you won't be able to access files belonging to other groups you're a member of.
setuidgidfrom daemontools-encore and the
setuidgidfrom the nosh toolset both have an
--supplementary) option which will put you in that group, and also put you in all of the supplementary groups for the user that you specify.
newgrp once you've become the less privileged user will add a single group to your groupset, but also creates a new subshell, making it tricky to use inside scripts.
start-stop-daemon preserves your group membership, and does a whole lot more than just setuid/setgid.
chpst -u username:group1:group2:group3... commandname will let you specify exactly what group memberships to adopt, but (in Ubuntu) it only comes with the
runit package, which is an alternative to
su -c commandname username picks up all of username's group memberships, as does
sudo -u username commandname, so they're probably the route to least astonishment.
setuidgid from the package
Documentation here: http://cr.yp.to/daemontools/setuidgid.html
On an Ubuntu 10.10 instance on Amazon EC2, I had better luck with the
I also struggled with some of the other upstart stanzas. I am calling a python application with a specific
virtualenv and some parameters to my executed program.
The following is what worked for me.
script export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/ exec start-stop-daemon --start --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 & end script
PYTHONPATH is to get some packages installed from source into the PYTHON module path when this upstart job runs. I had to do everything in absolute paths because the
chdir stanza didn't seem to do work.
I was using CentOS 6, and I could not get the recommended hack (for Upstart 0.6.5) to work for me, nor the 'su' trick because the number of forks involved (4 I think) was not tracked by 'expect fork' or 'expect daemon'.
I eventually just did
chown user:group executable chmod +s executable
(ie set the setuid bit and change the ownership).
It may not be the safest method, but for an internal R&D project, it didn't matter in our case.
In CentOS 6, upstart 0.6.5, the following is what worked for me.
script exec su user_name << EOF exec /path/to/command [parameters...] EOF end script
script exec su user_name << EOF ..... what you want to do .... EOF end script
exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]
the job process can't be stopped by
initclt stop .
I think the reason is:
1. the job forked and the main process is not tracked. 2. the main process changed its process group,because of `su -c`
There is a third possibility depending on what you are trying to accomplish. You may be able to loosen the access controls on the files/devices in question. This can allow an unprivileged user to mount or access items that they normally wouldn't be allowed to. Just be sure you aren't giving away the keys to the kingdom in the process.
You can also change the timeout of the sudo password cache. But I don't recommend it unless your machine is physically secure (i.e., you believe that it's unlikely that a passer-by would attempt to gain sudo access).
There's a good reason that there are very few ways to perform privileged actions and that they perform
needless necessary logging. Loose restrictions would be a security hazard for your system, and a lack of logging would mean there's no way to know what happened when you've been compromised.
If the size of your log files is a concern then something is probably wrong. Sudo generates only one line per use under normal conditions.