On Mon, Oct 19, 2020 at 08:11:01PM -0700, David Christensen wrote:
> On 2020-10-19 05:00, Greg Wooledge wrote:
> > using an explicit /usr/bin/rsync is sketchy at best. You
> > should already have /usr/bin in your PATH
>
> AIUI using absolute paths for tools in shell scripts is a security best
> practice -- it helps defend against attacks where PATH is compromised and/or
> trojaned system tools are inserted into directories at the front of PATH.
It's not "best practice", and it does not provide any security against
a malevolent execution environment. All it really does is introduce
failures when the location of a tool changes. (See all the instances
of failures when new buster installations moved some tools from /bin
to /usr/bin, and scripts were updated to use things like /usr/bin/mkdir,
which then fails on *upgraded* buster systems.)
To illustrate why it doesn't provide any security protection:
unicorn:~$ function /bin/rm { echo "haha loser"; }
unicorn:~$ /bin/rm xyzzy
haha loser
Remember, bash can accept functions that are imported from the environment,
and bash's functions have an extremely liberal allowed set of characters.
Granted, that same feature/problem will not apply to non-bash scripts,
but even with a #!/bin/sh shebang, it's still common for systems to
have /bin/sh -> bash (even on Debian, it is a supported configuration).
> Using absolute paths for tools also means that the script will work when
> cron(8) runs it (or runs something that runs it).
You can set PATH at the top of the script.
In any case, /usr/bin should be in PATH, even in the most barebones cron
environment. On Debian, crontab(5) says:
Several environment variables are set up automatically by the cron(8)
daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
/etc/passwd line of the crontab's owner. PATH is set to
"/usr/bin:/bin". HOME, SHELL, and PATH may be overridden by settings
in the crontab; LOGNAME is the user that the job is running from, and
may not be changed.
