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 -execdiring 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 cds to ~eve/shared/blah and runs wc *.c. If blah contains Eve's wc script, do_evil runs as Alice.
