Merits of using full path to executables in scripts

Ranguvar · 2009-03-01 07:41:56

I remember seeing a while back someone's post (on another forum, or mailing list) about the merits of using full paths to executables in shell scripts. Examples include typing /usr/bin/setleds into /etc/rc.local to turn numlock on at boot, or many of Arch's PKGBUILDs and install scripts, which access apps like sed directly.

So, I've been debating with myself over whether to follow this practice in scripts like rc.local. Obviously it limits flexibility if the binary moves (e.g. new package) - although this is unlikely, I'd like to have a good convention. Does this make sense, and where? Discuss

TheBodziO · 2009-03-02 23:54:53

I think most important reason here is security. If you're using only binary name, then somebody could, by modifying your $PATH, trick you to run e.g. malicious binary named "ifconfig" placed in other place that "ifconfig" you intended to run. If you're using full path to binary this potential threat is greatly reduced.

As for portability you can always use a couple of variables on the beginning of your script that'll point to binaries you are about to use in your code, I mean:

SUDO=/usr/bin/sudo
$SUDO /etc/rc.d/samba start

It makes potential porting easy.

R00KIE · 2009-03-03 00:16:52

Well it ensures it will always find the executable. I have also seen cases where things will work once and fail afterwards if I don't use the full path. One of those is something like this:

#!/bin/bash
watch -n 300 /usr/bin/xscreensaver-command -deactivate

I use this to stop the screensaver from activating when watching a movie with mplayer. If I don't use the full path then for some reason it will only work the first time its called, afterwards it will keep complaining that it can't find the executable .... beats my limited knowledge

pointone · 2009-03-03 00:23:04

I always understood it to be a security thing, as it is possible for malicious scripts to change your path as TheBodzIO describes.

Alternatively, you should declare your PATH at the beginning of a script, as in:

#! /bin/bash

PATH=/bin:/sbin

echo "Doing things..."
...
...
...

I remember reading a great article that explained all this... but was unable to find it.

Last edited by pointone (2009-03-03 00:23:51)

Yannick_LM · 2009-03-03 00:27:27

R00KIE wrote:

I use this to stop the screensaver from activating when watching a movie with mplayer

mplayer -stop-xscreensaver does not work ?

Ranguvar · 2009-03-03 01:12:40

Good idea, pointone (declaring PATH first)!

R00KIE · 2009-03-03 14:45:37

Yannick_LM wrote:

R00KIE wrote:
I use this to stop the screensaver from activating when watching a movie with mplayer
mplayer -stop-xscreensaver does not work ?

I don't want it to stop the screensaver from activating (and locking the screen) if I'm just listening music, mind you that I use smplayer with mplayer.
Also I have tried it once and it didn't seem to work for me.

On the path idea, looks good but shouldn't you save the current path before setting a new one so you can restore it at the end?

DonVla · 2009-03-03 15:39:41

Ranguvar wrote:

Obviously it limits flexibility if the binary moves (e.g. new package) - although this is unlikely, I'd like to have a good convention. Does this make sense, and where? Discuss

as long as you're using bash you can use the built-in "type"

$ type -P bash
/bin/bash

man bash:

If the -p option is used, type either returns the name of the disk file that would be executed if name were specified as a command name, or nothing if "type -t name'' would not return file.
The -P option forces a PATH search for each name, even if "type -t name'' would not return file. If a command is hashed, -p and -P print the hashed value, not necessarily the file that appears first in PATH.

fukawi2 · 2009-03-03 22:46:00

I always do it how TheBodziO said... Use a variable for the full path then 'execute the variable'. I always know I'm executing the correct binary, and not some rouge or alias that might alter the output.

pointone · 2009-03-04 02:24:22

R00KIE wrote:

On the path idea, looks good but shouldn't you save the current path before setting a new one so you can restore it at the end?

If using a shebang, or executing "bash /path/to/script", the script will be run in a subshell, so it won't effect the PATH of the original environment, AFAIK.

Arch Linux

#1 2009-03-01 07:41:56

Merits of using full path to executables in scripts

#2 2009-03-02 23:54:53

Re: Merits of using full path to executables in scripts

#3 2009-03-03 00:16:52

Re: Merits of using full path to executables in scripts

#4 2009-03-03 00:23:04

Re: Merits of using full path to executables in scripts

#5 2009-03-03 00:27:27

Re: Merits of using full path to executables in scripts

#6 2009-03-03 01:12:40

Re: Merits of using full path to executables in scripts

#7 2009-03-03 14:45:37

Re: Merits of using full path to executables in scripts

#8 2009-03-03 15:39:41

Re: Merits of using full path to executables in scripts

#9 2009-03-03 22:46:00

Re: Merits of using full path to executables in scripts

#10 2009-03-04 02:24:22

Re: Merits of using full path to executables in scripts

Board footer