> 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.
This is also what musl-libc do, except that it does not bother trying
something
else if that fails.
> It would be that or
> have the kernel store the whole path for the life of the process for
> obtaining with sysctl()
That would be great. ps and top would be able to display the path too,
pretty handy.
On Fri, Dec 11, 2015 at 9:04 PM, Philip Guenther <guent...@gmail.com> wrote:
> 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
--
Aurélien Vallée
Phone +33 9 77 19 85 61
