On Fri, Dec 11, 2015 at 10:18 AM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> Just found I can set LD_DEBUG to see the full translation process of ld.so. >> This seems to confirm what I've seen in the source: ld.so uses cwd >> instead of process file location for $ORIGIN interpolation. > ^^^^^^^^^^^^^^^^^^^^^ > > What is that? Generally Unix has no way of doing this. You can inspect > your executable's __progname, which is cloned from argv at crt startup, > but it may not contain an absolute path. So what do you really mean here?
I'm not sure what Solaris does for this, but it looks like glibc on Linux does readlink("/proc/self/exe") and if that fails and the process trusts its environment** then it falls back to the LD_ORIGIN_PATH environment variable. $ORIGIN then expands to dirname() of that. What's desired, I think, is to base it on the resolved (ala realpath()) value of the 'path' argument to execve(). At least that's what the Solaris docs seem to imply. Doesn't matter if that path resolves to a different underlying file later: it's just going to be used for the directory part anyway and it's ignored for privileged processes. I guess we could stick 'path' into an auxiliary vector value and have ld.so do the realpath() call if $ORIGIN is used? It would be that or have the kernel store the whole path for the life of the process for obtaining with sysctl(). Right now it only stores the last component of the (resolved) original path in p_comm. Philip Guenther ** i.e, not marked as 'secure', their sorta-similar-to-issetugid-but-not-really