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

Reply via email to