I often need to run at jobs as a different user. I've always done something like
$ echo "$PWD/batchToRun -parameters" | sudo su - otheruser -c "at now"
batchToRun
is also scheduled to run via otheruser's crontab. This works out well until batchToRun
starts depending on subtle side-effects of settings of environmental variables -- like LANG (sort anyone?) -- that are passed in from the environment of the user running sudo
.
I typically don't want to log in as otheruser; it's a semi-privileged account and I would like a "paper trail" of its associated activity so that I can go back and see exactly what was done, by whom, when, etc.
Besides the obvious rewriting batchToRun
to be independent of such settings, what's a good way to ensure that the sudoer's environment doesn't contaminate the target environment?
Note: this is on FC7 (sudo version 1.6.8p12) and other old distros, so any shiny new features of sudo
/su
/at
(notably, the ability to pass an argument with -i
to sudo
) are outside my grasp.
Update: it turns out that the su - otheruser
is actually a sufficient firewall between the users and that my contamination is coming from something in the interactive startup sequence. I still like the env
edit capability, though.
You could strip the environment before you run at
:
echo "command ..." | env - PATH="$PATH" sudo su - otheruser -c "at now"
You can also arrange for sudo
to do this for you by setting the env_reset
option. For example, you could give your user access to run the at
command as otheruser directly (rather than sudo
to root and then to the other user) and then set env_reset with a Defaults
command for that user or that command (see the sudoers man page).
But the above is probably the easiest solution without changing how you're generally doing things today.