In another question, the answer states that on Unixes with /proc, the really straight and reliable way is to readlink("/proc/self/exe", buf, bufsize) and it then proceeds to give backup solutions as follows:

On Unixes without /proc (i.e. if above fails):

• If argv[0] starts with "/" (absolute path) this is the path.
• Otherwise if argv[0] contains "/" (relative path) append it to cwd (assuming it hasn't been changed yet).

getcwd(buf, bufsize); strncat(buf, "/", bufsize-strlen(buf)-1);
strncat(buf, argv[0], bufsize-strlen(buf)-1);

• Otherwise search directories in $PATH for executable argv[0].

Afterward it may be reasonable to check whether the executable isn't actually a symlink. If it is resolve it relative to the symlink directory.

Now in my case, unfortunately, none of the above works:

1. /proc/self/exe exi开发者_JS百科sts but fail to readlink() due to permission denied errno 13.
2. The argv[0] has no / for absolute or relative path.
3. The $PATH does not contain the executable found in argv[0].

It appears this issue is faced also when sgid applications run. In my case, it is not sgid, but an inetd launch.

The best way to solve this is in the /etc/xinetd.d/myApp configuration file, to add an environment variable that specifies the location of the binary like this:

service myApp
{
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    server = /usr/local/bin/myAppd
    env = MY_APP_HOME=/usr/local/bin
    port = 2354
    disable = no
}

Then, if /proc/self/exe is permission denied, check for the env varible and use it instead.

Try looking in /proc from a suid binary.

I think that the answer is: give up.

Ask the user to pass the install directory (or whatever you are looking for) as a command line argument.

As a last resort, parse the /etc/xinetd.d/myApp file to pull out the server line which includes the complete path to the executable summoned via inetd.