bin/47509: ld.elf_so does not expand variables (such as $PLATFORM) in LD_PRELOAD

[csunstrum%coverity.com@localhost]

>Number:         47509
>Category:       bin
>Synopsis:       ld.elf_so does not expand variables (such as $PLATFORM) in 
>LD_PRELOAD
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 28 22:55:00 +0000 2013
>Originator:     Caleb Sunstrum
>Release:        5.0.2
>Organization:
Coverity
>Environment:
NetBSD t-netbsd5x64-vm01 5.0.2 NetBSD 5.0.2 (GENERIC) #0: Sat Feb  6 13:44:19 
UTC 2010  
builds%b8.netbsd.org@localhost:/home/builds/ab/netbsd-5-0-2-RELEASE/amd64/201002061851Z-obj/home/builds/ab/netbsd-5-0-2-RELEASE/src/sys/arch/amd64/compile/GENERIC
 amd64

>Description:
When setting LD_PRELOAD=/some/path/to/lib/libfoo-${PLATFORM}.so, you will get 
this error when attempting to run anything:

Cannot open "/some/path/to/lib/libfoo-${PLATFORM}.so"

From browsing the code, this looks to be because the rtld calls 
_rtld_preload(env['LD_PRELOAD']), which in turn splits the path on ':', and 
passes the individual paths to _rtld_load_object(), which assumes path 
expansion has already occurred.

Conversely, when parsing LD_LIBRARY_PATH, _rtld_add_paths() is used, which in 
turn calls _rtld_expand_path(), which processes these variables.

As a further problem, a workaround where LD_LIBRARY_PATH is set and LD_PRELOAD 
is assigned a relative path is not possible, as the same process path 
essentially requires an absolute path in LD_PRELOAD (library paths are not 
searched).
>How-To-Repeat:
export LD_PRELOAD='/path/to/lib/libfoo-${PLATFORM}.so'
ls

'ls' will fail with 'Cannot open "/path/to/lib/libfoo-${PLATFORM}.so".
>Fix:
Haven't tested it, but I would assume changing _rtld_preload so that it calls 
_rtld_load_object(_rtld_expand_path(path)) would fix the failure to expand 
variables. Allowing relative paths would require more involved changes.