[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180127110722.GI4418@port70.net>
Date: Sat, 27 Jan 2018 12:07:22 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Stefan Fröberg <stefan.froberg@...roprogram.com>
Cc: musl@...ts.openwall.com
Subject: Re: BUG: $ORIGIN does not seem to work
* Stefan Fröberg <stefan.froberg@...roprogram.com> [2018-01-27 01:50:21 +0200]:
> My ldd is just symbolic link inside musl chroot environment, to
> /lib/ld-musl-x86_64.so.1
> and it's symbolic link to /lib/libc.so
>
> Here is readelf output of that test program
> readelf -d x
>
> Dynamic section at offset 0xe10 contains 24 entries:
> Tag Type Name/Value
> 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
^^^^^^^^^^^^^^^^
this looks like the wrong library version
if you had straced the ldd output you would have seen
that musl tries to open lib/libcrypto.so.1.1, but you
probably only have lib/libcrypto.so.1.0.0 based on the
glibc ldd output below.
at link time you need to make sure ld picks up the
right libcrypto.
> 0x0000000000000001 (NEEDED) Shared library: [libc.so]
> 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib]
> 0x000000000000000c (INIT) 0x598
> 0x000000000000000d (FINI) 0x812
> 0x000000006ffffef5 (GNU_HASH) 0x220
> 0x0000000000000005 (STRTAB) 0x390
> 0x0000000000000006 (SYMTAB) 0x258
> 0x000000000000000a (STRSZ) 241 (bytes)
> 0x000000000000000b (SYMENT) 24 (bytes)
> 0x0000000000000015 (DEBUG) 0x0
> 0x0000000000000003 (PLTGOT) 0x201000
> 0x0000000000000002 (PLTRELSZ) 48 (bytes)
> 0x0000000000000014 (PLTREL) RELA
> 0x0000000000000017 (JMPREL) 0x568
> 0x0000000000000007 (RELA) 0x4c0
> 0x0000000000000008 (RELASZ) 168 (bytes)
> 0x0000000000000009 (RELAENT) 24 (bytes)
> 0x000000006ffffffb (FLAGS_1) Flags: PIE
> 0x000000006ffffffe (VERNEED) 0x4a0
> 0x000000006fffffff (VERNEEDNUM) 1
> 0x000000006ffffff0 (VERSYM) 0x482
> 0x000000006ffffff9 (RELACOUNT) 2
> 0x0000000000000000 (NULL) 0x0
>
> So the $ORIGIN/lib is there but for some reason ldd won't show it???
>
> Best Regards
> Stefan Fröberg
>
> Szabolcs Nagy kirjoitti 26.01.2018 klo 16:21:
> > * Stefan Fröberg <stefan.froberg@...roprogram.com> [2018-01-26 15:39:23 +0200]:
> >> On glibc the following:
> >>
> >> gcc -o x -Wl,-rpath='$ORIGIN/lib' x.c -L ./lib -lcrypto
> >>
> >> or
> >>
> >> gcc -o x -Wl,-rpath,'$ORIGIN/lib' x.c -L ./lib -lcrypto
> >>
> >> Gives me binary with relative library path
> >>
> >> ldd x
> >> linux-vdso.so.1 (0x00007ffcb6bee000)
> >> * libcrypto.so.1.0.0 => /home/wizard/kal-el/lib/libcrypto.so.1.0.0
> >> (0x00007f0bc3593000)**
> >> * libc.so.6 => /lib64/libc.so.6 (0x00007f0bc31e2000)
> >> libdl.so.2 => /lib64/libdl.so.2 (0x00007f0bc2fde000)
> >> libz.so.1 => /lib64/libz.so.1 (0x00007f0bc2dc7000)
> >> /lib64/ld-linux-x86-64.so.2 (0x00007f0bc39d2000)
> >>
> >> cp -rap kal-el/* batman/
> >> ldd x
> >> linux-vdso.so.1 (0x00007ffdbf0b6000)
> >> * libcrypto.so.1.0.0 => /home/wizard/batman/lib/libcrypto.so.1.0.0
> >> (0x00007fb682149000)**
> >> * libc.so.6 => /lib64/libc.so.6 (0x00007fb681d98000)
> >> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb681b94000)
> >> libz.so.1 => /lib64/libz.so.1 (0x00007fb68197d000)
> >> /lib64/ld-linux-x86-64.so.2 (0x00007fb682588000)
> >>
> >>
> >> But trying the same with musl does not seem to work?
> >> ldd x
> >> /lib/ld-musl-x86_64.so.1 (0x7f07372e2000)
> >> libc.so => /lib/ld-musl-x86_64.so.1 (0x7f07372e2000)
> >>
> >> and if i remove the -L ./lib from the command it uses system library
> >> gcc -o x -Wl,-rpath,'$ORIGIN/lib' x.c -lcrypto
> >> ldd xx
> >> /lib/ld-musl-x86_64.so.1 (0x7fdd8618d000)
> >> libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7fdd85ed7000)
> >> libc.so => /lib/ld-musl-x86_64.so.1 (0x7fdd8618d000)
> >>
> >>
> > $ORIGIN in rpath works fine in musl
> >
> > you are doing something wrong
> >
> > but it's hard to tell what: your ldd command is looking at
> > the wrong binary, we don't know what ldd you are using (e.g.
> > use ld-*-musl.so.1 --list foo to make this explicit), it's
> > not clear if the binary has $ORIGIN set up correctly since
> > you showed a gcc command line instead of readelf -d of the
> > generated executable, we don't know what paths have the
> > library and what paths the ldso tried (you can check this
> > by strace).
> >
> > (there are some differences between musl and glibc:
> > e.g. glibc expands $ORIGIN in dlopen too while musl does
> > not, however in your case musl should work)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
