[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CFT5A0ZYEAVE.4TCYHZMANU1K@mussels>
Date: Thu, 18 Nov 2021 16:15:52 -0300
From: Érico Nogueira <ericonr@...root.org>
To: "Alexander Sosedkin" <monk@...oiled.info>, <musl@...ts.openwall.com>
Cc: <monk@...oiled.info>
Subject: Re: $ORIGIN rpath expansion without /proc: code looks wrong
On Wed Nov 17, 2021 at 4:25 PM -03, Alexander Sosedkin wrote:
> On 11/17/21 18:00, Érico Nogueira wrote:
> > On Wed Nov 17, 2021 at 11:04 AM -03, Alexander Sosedkin wrote:
> >> Hello, I've encountered a case of a binary with an rpath of
> >> /some/meaningful/lib:$ORIGIN/../lib
> >> not starting up due to not finding /some/meaningful/lib/libxyz.so.
> >> ldd'ing said it's there though.
> >> And the library was found alright when I patchelf'd rpath to just
> >> /some/meaningful/lib
> >>
> >> I dug into musl code and came across that bit that checks /proc.
> >> Sure enough, when I tried mounting /proc, it started working fine.
> >> Yet the error handling from accessing /proc puzzles me:
> >>
> >> ldso/dynlink.c, fixup_rpath():
> >> l = readlink("/proc/self/exe", buf, buf_size);
> >> if (l == -1) switch (errno) {
> >> case ENOENT:
> >> case ENOTDIR:
> >> case EACCES:
> >> break;
> >> default:
> >> return -1;
> >> }
> >> if (l >= buf_size)
> >> return 0;
> >> buf[l] = 0;
> >> origin = buf;
> >>
> >> hitting that break like I had means zeroing buf[-1], right?
> >
> > No. Because `l` is size_t (unsigned long), it's the biggest possible
> > value for size_t, and `l >= buf_size` will be true,
>
> Oh! Thanks a lot, that's what confused me. Sorry for the noise then.
>
> > which means the
> > function returns 0. This conditional also catches the case where
> > truncation happens in readlink(3).
> > Documenting this in a comment or changing `break;` for `return 0;` might
> > make sense, though.
>
> Yeah, I'd say a `return 0;` there would've been easier to comprehend.
> I don't think there's much need for a comment...
That sounds reasonable to me. I can make a patch for it.
>
> >> Could somebody take a look at this and double-check that
> >> this codepath makes sense?
> >
> > It does, but it might not be as robust as you wish. fixup_rpath() treats
> > the RPATH entry as a single string, and does all $ORIGIN substitutions
> > in one go (what splits the string by ":" is open_path()). This means
> > that the entire RPATH entry containing $ORIGIN will be ignored if
> > /proc/self/exe can't be accessed, despite one or more of them not
> > depending on $ORIGIN.
>
> ... because if running /proc-less isn't supported in general,
> then such separate expansions are probably not worth the effort.
> And it's far from being the only mention of /proc in the code,
> so I'm going to presume it's not.
https://musl.libc.org/doc/1.1.24/manual.html does document the
requirement that /proc exist, and at a an arbitrary guess, complex
binaries which rely on RPATH are unlikely to run before the boot process
has mounted /proc.
I can think of some ways to try and change the order the operations are
done in, but in the end, it's probably not worth it to make changes to
this part of the code.
>
> >> My attempts at comprehending it fail irrecoverably at this line.
> >>
> >> (CC me on replies, please.
> >> No nice context to provide, building my own toolchain at
> >> https://github.com/t184256/bootstrap-from-tcc)
>
> Thanks for the answer, appreciated.
Glad to help!
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.
