[PATCH][v2] Add dynamic linker support for $EXEC_ORIGIN.

Mike Frysinger vapier@gentoo.org
Fri Dec 20 20:06:00 GMT 2013


On Thursday 12 December 2013 17:13:39 Brooks Moses wrote:
> Updated to address Paul's comments about using getsauxval().
> 
> 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().
> 
> One potential security risk of such a token expansion is that, although
> copying a setuid/setgid executable (to change its $ORIGIN) loses the
> setuid/setgid bit, creating a symlink does not -- and so a user could
> inject arbitrary code into a setuid/setgid executable that references
> $EXEC_ORIGIN by creating an appropriate symlink.  In order to slam the
> door shut on this security risk, this patch simply prohibits the use of
> $EXEC_ORIGIN in setuid/setgid binaries.

this probably should be documented somewhere in glibc (beyond just the code 
itself).  a quick scan of the manual though doesn't seem to turn up any 
discussion of topics like rpath or $ORIGIN, so i guess the assumption is that 
we follow the standard ELF conventions.  which leads into the next point ...

shouldn't it also be coordinated (at least loosely) with the linker and ELF 
ABI peeps ?  they already fully document (and in some cases implement) the 
semantics of DT_RPATH/DT_RUNPATH, so having glibc add its own (undocumented) 
extensions doesn't seem like a good idea.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20131220/661edef6/attachment.sig>


More information about the Libc-alpha mailing list