This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping^6: [PATCH][v3] Add dynamic linker support for $EXEC_ORIGIN.
- From: Brooks Moses <bmoses at google dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, "Carlos O'Donnell" <carlos at redhat dot com>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Fri, 21 Mar 2014 15:18:46 -0700
- Subject: Re: Ping^6: [PATCH][v3] Add dynamic linker support for $EXEC_ORIGIN.
- Authentication-results: sourceware.org; auth=none
- References: <CAOxa4Kqowxbb6Pm17JooE454BNfJKNMnhhVE50pGjoaVs4YsJg at mail dot gmail dot com> <20140321195912 dot 2CC7A744AC at topped-with-meat dot com>
On Fri, Mar 21, 2014 at 12:59 PM, Roland McGrath <roland@hack.frob.com> wrote:
> The implementation is less of the issue here than making the case for the
> feature.
Certainly. I explained the case for the feature in my initial
description of the patch (and I'll requote that below); I'm not clear
if you didn't see that, or if you're implying that it needs more
elaboration and/or stronger justification. Could you clarify? I'm
happy to elaborate if that's what you're asking for.
I wrote:
> The $ORIGIN rpath token expands to the directory containing the true
> copy of the application executable -- which is to say, if the executable
> is invoked through a symlink, that symlink will be resolved in the
> $ORIGIN substitution.
>
> In some cases, such as symlink farms backed by cloud storage filesystems
> where the resolved path encodes effectively-arbitrary storage data, it
> is much more useful to have a rpath token that points to the
> non-expanded, as-called version of the executable path. This patch adds
> the $EXEC_ORIGIN token for this purpose, resolving to the executable
> path as passed to execve().
Thanks,
- Brooks