You could run the wrong program. Someone could make you run their program.
The -execdir
action runs your command from the directory that contains the file(s) found. When $PATH
contains relative paths, such as .
or anything that doesn't start with /
, -execdir
is insecure because a directory where a file is found (or another directory resolved relative to it) could also contain an executable of the same name as the one you are trying to run. That potentially untrusted executable would then get run instead.
This could be deliberately exploited by another user to cause you to run their program, which might cause harm or breach data security, instead of the program you are trying to run. Or, less often, it might simply result in the wrong program inadvertently being run, even without anyone trying to make the problem happen.
If everything in your PATH
environment variable is an absolute path, this error should not occur, even if the directory you're searching and -execdir
ing from is contained in PATH
. (I've checked that this works.) If you believe you don't have any relative directories in $PATH
but are still getting this error, please update your question with details including the output of echo "$PATH"
.
A concrete example.
As an example of what could go wrong, suppose:
- Alice has
.
in her $PATH
because she wants to be able to run programs in whatever directory she's cd
'd to, without bothering to prepend their names with ./
.
- Alice's frenemy Eve has shared
/home/eve/shared
with Alice.
- Alice wants statistics (lines, words, bytes) on the
.c
files Eve has shared with her.
So Alice runs:
find ~eve/shared -name \*.c -execdir wc {} \;
Unfortunately for Alice, Eve has created her own script, named it wc
, set it executable (chmod +x
), and placed it clandestinely in one of the directories under /home/eve/shared
. Eve's script looks like this:
#!/bin/sh
/usr/bin/wc "$@"
do_evil # Eve replaces this command with whatver evil she wishes to do
So when Alice uses find
with -execdir
to run wc
on the files Eve has shared, and it gets to files in the same directory as Eve's custom wc
script, Eve's wc
runs--with all of Alice's privileges!
(Being crafty, Eve has made her wc
script act as a wrapper for the system wc
, so Alice won't even know something has gone wrong, i.e., that do_evil
was run. However, simpler--and also more sophisticated--variations are possible.)
How find
prevents this.
find
prevents this security problem from happening by refusing to take the -execdir
action when $PATH
contains a relative directory.
find
offers two diagnostic messages depending on the specific situation.
If .
is in $PATH
, then (as you've seen) it says:
find: The current directory is included in the PATH environment variable, which is insecure in combination with the -execdir action of find. Please remove the current directory from your $PATH (that is, remove "." or leading or trailing colons)
It probably has a special message for the .
case as it's especially common.
If a relative path other than .
--say, foo
--appears in $PATH
and you run find
with -execdir
, it says:
find: The relative path `foo' is included in the PATH environment variable, which is insecure in combination with the -execdir action of find. Please remove that entry from $PATH
It's better not to have relative paths in $PATH
at all.
The risk of having .
or other relative paths in $PATH
is especially heightened when using a utility that automatically changes the directory, which is why find
won't let you use -execdir
in this situation.
But having relative paths, especially .
, in your $PATH
is inherently risky and is really best avoided anyway. Consider the fictional situation in the example above. Suppose instead of running find
, Alice simply cd
s to ~eve/shared/blah
and runs wc *.c
. If blah
contains Eve's wc
script, do_evil
runs as Alice.