mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "Érico Nogueira" <ericonr@disroot.org>
To: "Alexander Sosedkin" <monk@unboiled.info>, <musl@lists.openwall.com>
Cc: <monk@unboiled.info>
Subject: Re: [musl] $ORIGIN rpath expansion without /proc: code looks wrong
Date: Thu, 18 Nov 2021 16:15:52 -0300	[thread overview]
Message-ID: <CFT5A0ZYEAVE.4TCYHZMANU1K@mussels> (raw)
In-Reply-To: <256fa366-6e6b-8248-3176-1736c8db55a4@unboiled.info>

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!


  reply	other threads:[~2021-11-18 19:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 14:04 Alexander Sosedkin
2021-11-17 17:00 ` Érico Nogueira
2021-11-17 19:25   ` Alexander Sosedkin
2021-11-18 19:15     ` Érico Nogueira [this message]
2021-11-17 20:01   ` Jeffrey Walton
2021-11-18 19:21     ` Érico Nogueira
2021-11-18 19:41       ` Alexander Sosedkin
2021-11-18 19:42       ` Jeffrey Walton
2021-11-18 20:30         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CFT5A0ZYEAVE.4TCYHZMANU1K@mussels \
    --to=ericonr@disroot.org \
    --cc=monk@unboiled.info \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).