Re: Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename

[Guillem Jover]

Hi!

On Fri, 2016-06-10 at 02:20:15 +0100, Steven Chamberlain wrote:
> Package: uid-wrapper
> Version: 1.2.0+dfsg1-1
> Severity: normal
> Tags: patch
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd

> I found this happens because src/uid_wrapper.c doesn't detect the libc's
> filename.  It matches libc.so.[0-9] whereas on kfreebsd it is named
> libc.so.0.1 currently.
> 
> The same problem will affect hurd too, which has libc.so.0.3 (although
> there are other reasons for FTBFS on hurd).
> 
> Please consider the attached patch to detect libc.so.0.[0-9] as well.
> Unless there is some neater way to do this.  Thanks a lot!

Yeah, I think the initial approach is just wrong. Consider if we ever
had an (unlikely) SONAME bump for libc, the library might end up linked
against libc.so.7 and the code loading libc.so.6. Depending on the
intended usage there are possibly better ways to achieve that.

If the library is supposed to be pre-loaded then using RTLD_NEXT as
the handle is way better, and avoids having to use an explicit library
name.

If it's not, on GNU systems we can always use LIBC_SO and LIBPTHREAD_SO
from , for example. Otherwise on non-GNU ELF systems,
we could link a small program and then readelf (or objdump) it to find
the NEEDED entry for libc. Or we could also try to readlink the libc.so
symlink and make sure it's an ELF object at build time to try to get the
SONAME (this will fail on at least GNU systems as the libc.so is a linker
script there).

Thanks,
Guillem

Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename

[Steven Chamberlain]

Package: uid-wrapper
Version: 1.2.0+dfsg1-1
Severity: normal
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hi,

uid-wrapper FTBFS on kfreebsd because of segfaults running every test:

| Program terminated with signal 11, Segmentation fault.
| #0  0x0008006156e1 in _dl_close () from /lib/ld-kfreebsd-x86-64.so.1
| #1  0x00080060f7d4 in _dl_catch_error () from /lib/ld-kfreebsd-x86-64.so.1
| #2  0x000800f99511 in _dlerror_run () from 
/lib/x86_64-kfreebsd-gnu/libdl.so.2
| #3  0x000800f98fef in dlclose () from /lib/x86_64-kfreebsd-gnu/libdl.so.2
| #4  0x000800825281 in uwrap_destructor () at
| /home/steven/uid-wrapper-1.2.0+dfsg1/src/uid_wrapper.c:2133
| u = 
| #5  0x00080060ff17 in _dl_fini () from /lib/ld-kfreebsd-x86-64.so.1
| #6  0x000800c69a78 in __run_exit_handlers () from 
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #7  0x000800c69ac5 in exit () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #8  0x000800c551a7 in __libc_start_main () from 
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #9  0x00400847 in _start ()
https://buildd.debian.org/status/fetch.php?pkg=uid-wrapper=kfreebsd-amd64=1.2.0%2Bdfsg1-1=1449681825

I found this happens because src/uid_wrapper.c doesn't detect the libc's
filename.  It matches libc.so.[0-9] whereas on kfreebsd it is named
libc.so.0.1 currently.

The same problem will affect hurd too, which has libc.so.0.3 (although
there are other reasons for FTBFS on hurd).

Please consider the attached patch to detect libc.so.0.[0-9] as well.
Unless there is some neater way to do this.  Thanks a lot!

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Date: Fri, 10 Jun 2016 02:06:45 +0100
From: Steven Chamberlain 
Subject: support libc soname 0.x

On some glibc-based platforms, the libc soname is not an integer, such
as 0.1 on kfreebsd and 0.3 on hurd.

--- a/src/uid_wrapper.c
+++ b/src/uid_wrapper.c
@@ -407,6 +407,11 @@
 if (handle != NULL) {
 	break;
 }
+snprintf(soname, sizeof(soname), "libc.so.0.%d", i);
+handle = dlopen(soname, flags);
+if (handle != NULL) {
+	break;
+}
 			}
 
 			uwrap.libc.handle = handle;