Loading glibc in a new namespace fails vtable check

[Florian Weimer]

* Moshe Rubin:

> I tried to reuse your code, but do not have access to the "support"
> folder, but was able to reproduce the crash:

The support/ folder provides test helpers for glibc.  There is a way to
use them outside of a glibc build:

  Accelerate glibc test development with the glibc-support repository 
  <https://developers.redhat.com/articles/2024/08/27/accelerating-glibc-test-development-glibc-support-repository>
> Three questions, if I may:
>
> 1. When you refer to inner and initial libc, is the default namespace
> the "initial libc", while the second namespace (via dlmopen) is the
> "inner libc"?  Is there a concept of inner and output libcs when
> dlmopen is called?  Aren't the namespaces independent of each other,
> acting in parallel to each other?

The initial libc (the one that calls dlopen) is definitely different
because ld.so uses its malloc, the libc malloc uses the brk system call,
it can create threads, call exit, fork etc.  Functionality of secondary
libcs loaded via dlmopen is more limited, many things just don't work
(and crash), some functionality is disabled explicitly.

> 2. Why does my original test program *not* throw a fatal error?  It is
> also cross-mixing the libc with an inner fwrite() with an initial
> "stderr"?  Is this what you said is a bug?

It's currently possible to pass a stream from the initial libc to a
secondary libc because vtable validation is disabled entirely for
secondary libcs.  I think I had plans to disable vtable validation for
the initial libc once it calls dlmopen, but evidently, I have not
implemented that.

> 3. If LIBC_SO is passed to dlmopen, is the function smart enough to
> find the absolute path?  In my test code, I read "/proc/self/maps",
> parsed it, etc.  Is such code unnecessary?

Yes, LIBC_SO typically expands to "libc.so.6", and that's sufficient to
locate the shared object.  Pretty much all binaries do not use a full
path either, it's the same search mechanism.

Thanks,
Florian