$0
could be whatever the caller of the script wants. This is the path to the script, and the caller could make a copy or link to the script in any location.
However this is not a vulnerability in itself unless the script is running with more privileges than its caller. Unless the script executable is privileged, the caller could run a different program. It may become a vulnerability if the caller is itself privileged and can be convinced to pass a different $0
.
If the script is running with privileges, then what $0
can be depends on the method used to elevate privileges. If the script is invoked through a symbolic link to a setuid executable then $0
could be arbitrary (however most systems refuse setuid executables).
Regardless of the lack of security implication in most scenarios in this particular case, your script is not fully robust against arbitrary $0
. The double quotes in "$0"
cause the value to be used as is (whereas an unquoted $0
would treat it as a list of wildcard patterns). But when the basename
command sees that value as an argument, it will treat it differently depending on whether the value starts with a -
. If the value starts with a -
(and isn't just -
) then it's an option. At least with GNU basename
, a non-option argument is mandatory, so calling it with a single argument that begins with -
would only result in an error. But this is be a bigger issue with some other commands. To cope with arbitrary values, including those beginning with -
, put --
before the argument to indicate that no more options follow: basename -- "$0"
.