[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Static binaries and nss (dlopen actually)
From: |
Samuel Thibault |
Subject: |
Static binaries and nss (dlopen actually) |
Date: |
Wed, 18 Feb 2015 02:26:33 +0100 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
Hello,
Static binaries currently can't make use of nss functions
(or more generally really use dlopen-ed libraries). What
happens is that when the nss plugin library gets loaded, e.g.
/lib/i386-gnu/libnss_files.so.2, by dependency libc.so gets loaded, i.e.
a *second* libc (the first being the one statically linked into the
binary). When the nss plugin tries to e.g. open /etc/passwd, it calls
open() from that second libc, which ends up calling _hurd_ports_use(),
which returns EGRATUITOUS because _hurd_ports is NULL: indeed the second
libc has not called _hurd_init to initialize itself.
So basically the concern is that the second libc hasn't initialized
its structures. Should we really do it? It'd notably mean a second
set of file descriptors, and thus plugin functions must not return
file descriptors since they'll not be in the same space as the
statically-linked application... Should we then rather manage that the
loaded libc.so accesses the statically-linked _hurd_ports etc?
This issue notably makes the busybox build abort.
Samuel
- Static binaries and nss (dlopen actually),
Samuel Thibault <=