Ordering of the PATH environment variable

Question

Locally here on Ubuntu 14.04, my $PATH looks something like this:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

When I manually define the path for cron jobs or in Puppet/Ansible provisioning configuration, I usually flip the PATH environment variable around like this:

PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

Is there a security best-practice for ordering the entries in the PATH environment variable? I'd assume that it'd be best to prefer entries in an sbin directory over entries in a bin directory. I've noticed that on certain RHEL boxes, the PATH omits /sbin by default.

That said, what would be a security best practice for the PATH environment variable for:

1. User Unix accounts.
2. Administrator Unix accounts.
3. Cron jobs/configuration management processes.

Answer 1

If there's a directory in the search path where someone you don't trust could write files, then the directory should not be in the path, period.

The order only matters if a command is present in more than one entry in the list. So the only case to consider is when someone trustworthy arranged to have one entry shadowing another, deliberately or not.

If it was deliberate, then the order should be to search the directories in order of local management: typically this means first ~/bin or equivalent if running under an account that has such a directory (not applicable to most system accounts), then /usr/local/bin, then the directories managed by the package manager /usr/bin/ and /bin.

In principle, there should not be any shadowing between sbin and bin directories. sbin directories are for commands that are only useful to a system administrator (this is why these directories are normally not in the path of users other than root). In principle there could be a command name for which you want to run a different executable as root, so sbin directories should be ahead of the corresponding bin directory — otherwise …/sbin/foo would never be executed since it would be shadowed by …/bin/foo for everyone.

The only case when there is an ambiguity is if there may have been accidental shadowing. In that case there isn't an obvious answer. Generally, it doesn't make much sense to put /usr/local/bin after /usr/bin: if you don't want the local administrator's choice of commands, then don't put /usr/local/bin in the search path at all (and remove /usr/local/lib from the library search path, etc.).

Between /usr/bin and /bin, in principle, one might want to shadow an executable from /bin (small version for boot time only) with one from /usr/bin (large version from a separately-mounted /usr partition), but tiny root partitions with a separate /usr are a very uncommon practice these days. It was a more common practice in the days when operating systems used significant disk space, but even then shadowing utilities in /bin with versions from /usr/bin was uncommon. The other order, putting /bin first, has a slight performance benefit (/bin is usually a lot smaller). On most systems there's no strong reason to prefer one order over the other. (On some systems /bin and /usr/bin are the same directory, but you shouldn't assume that unless you only ever work on recent versions of one of the distributions that do this.)

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin (or PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin) is usually the right setting for jobs running as root, and PATH=/usr/local/bin:/usr/bin:/bin for jobs not running as root. I don't see any good reason to deviate from that (except for the /usr vs. / inversion) except to cater for local variations (e.g. a site-specific directory on *BSD distinct from the packages installed to /usr/local). Security-wise, it doesn't matter, but functionality-wise, putting /usr/local ahead of /usr and / is either indifferent or necessary.

Answer 2

As this page is now the first or second search result for queries about Linux path precedence, path order, etc. it seems worth adding an explicit short answer:

PATH order precedence is determined first to last, with earlier entries having priority.

The earlier answer is correct that no entry with untrusted files (or write access to other users) should be in PATH. Unfortunately many development packages (go, npm, pip, etc.) include executable files which may need to be in PATH for integration or real-world usage.

That situation makes them good candidates for occurring later in the path as a best practice. Or conversely, if a custom executable that you require has the same name as a command you never use: with caution, you can put that earlier in the path.