<div dir="ltr">On Mon, Nov 14, 2011 at 12:05, Balazs Komuves <span dir="ltr"><<a href="mailto:bkomuves@gmail.com">bkomuves@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Unfortunately, there is no standardized way on different unix systems </div>to access the path of the executable running (it's not even fully<br>
clear what it means in the presence of symlinks, etc). Actually it seems <br>to be impossible to do this (without argv[0]) on certain BSD systems.</blockquote><div><br></div><div>Also note:</div><div><br></div><div>- argv[0] won't be a full pathname if the program was found via $PATH search</div>
<div><br></div><div>- it is possible for users to pass arbitrary argv[0] to the exec() family of system calls</div><div><br></div><div>- some programs use special argv[0] values (this probably doesn't practically matter), notably shells look for a leading "-" (which is normally provided by "login" or "sshd" etc.) to indicate a login shell that should source ~/.profile etc.</div>
<div><br></div><div>- there are various other special cases, such as a number of Unixlikes implementing setuid shell scripts securely by passing a /dev/fd/* reference as argv[0] to avoid symlink attacks. Again, you *probably* don't need to care about this one, but there may be others on various systems.</div>
<div><br></div><div>In short, argv[0] should not be relied on as the executable name.</div><div><br></div><div>(The usual way this is managed is that the real executable is something like foo.real and foo is a shell script which passes in the path to foo.real as a parameter. During installation/configuration the shell script is modified as necessary to provide the correct path.)</div>
</div><div><br></div>-- <br>brandon s allbery <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available) (412) 475-9364 vm/sms<br>
<br>
</div>