As root, how do I read another user's environment variables?
I have a script that should be run using sudo, with the goal of "promoting" a script from a user-level installation to a system installation. Reproduced here:
Existing code
#!/bin/bash
if [[ $EUID -gt 0 ]]; then
echo "This script must run as root"
exit 1
fi
if [[ -z "${SUDO_USER-}" ]]; then
echo "Sudo user not found"
exit 1
fi
if [[ -z "${1-}" ]]; then
echo "Usage: sudo share-command SCRIPTNAME"
exit 1
fi
user_bin="$(getent passwd $SUDO_USER | cut -d: -f6)/.local/bin"
src="$user_bin/$1"
dst="/usr/local/bin/$1"
if [[ -f "$dst" ]]; then
echo "Already exists"
exit 1
fi
/usr/bin/install -m 755 "$src" "$dst"
Currently, it looks up the sudo user's home directory and looks in .local/bin relative to that.
I would like it to be able to find the script being installed by name.
I do not want to set the root user's PATH; I understand that this is insecure and there are protections against it. But given that the script is running as root, and I know who the sudo user is, it seems like I should be able to determine that user's PATH, and then iterate over it manually to look for the script.
Is this indeed possible? How?
1 answer
Nobody likes it when their ‘how can I do this?’ questions are answered with ‘don’t do this’, but while an answer could be given that would probably work well enough most of the time for many use cases, the question itself is contradicted by how environment variables and PATH in particular are expected to work.
An environment variable should not be presumed to be a static configuration value. It can be:
- Dynamically computed when a user's login session begins
- Modified by a user's shell (and a user may have different shells for different purposes)
- Extended or modified by various other parent processes a user may be running (such as, as you're discovering,
sudo!)
Consider a Python virtualenv as an example. A virtualenv is a local copy of a Python installation that can be isolated from a system-wide Python, in order to facilitate installing different versions of Python packages or even the Python interpreter itself. It works by setting the PATH in the current shell to point to where it stores its own executables, but other shells and other processes aren't affected.
A user who has entered a virtualenv will expect any of the tools they use to respect the PATH of the virtualenv. They would not want to run a script that then does something dodgy to read their ‘original’ PATH (whatever that even means, when PATH can be modified by several things between the user logging in and a shell prompt, some of which can be optional depending on things like whether the user is in a graphical session) and possibly run a Python interpreter that is not from the virtualenv they have entered. (Alternatively, if you are writing a script that requires a specific version of some utility such that you don't want to be subject to things like virtualenvs, your script should set its own PATH or refer to that utility by absolute path.)
The right question to ask is not ‘what is this user's PATH?’, but ‘what is the ambient PATH in the context of my script when it is invoked?’. And the right approach to this problem, if your script depends on sudo to function, is for your script to invoke sudo itself after collecting what it needs from the ambient environment.
0 comment threads
2 comment threads