From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Sat 09 Apr 2005 - 02:11:14 BST
sfrost_at_snowman.net (Stephen Frost) writes:
>> according to Enrico (please confirm or correct) the glibc has issues
>> with the fake name resolver and is generally considered insecure
>> because usually dynamically linked ...
> This really needs further explanation and justification. What about
> glibc being dynamically linked (and able to load other libraries)
> makes it insecure, specifically?
1. 'insecure', because the dynamical loading of libnss_* is
uncontrollable. There is no (documented??) way to disable this
loading e.g. when the chroot was entered. Executing a function which
would load an nss-library does not give any guarantee that the next
call to this function with another argument would not load another
2. the glibc NSS implementation uses caching/optimization which can
cause failures in chroot operations. E.g. when the 'getpwnam()'
before chroot(2) (which is used to load the libnss_* libraries)
creates a connection to the 'nscd' daemon, this connection will be
used for the second 'getpwnam()' (after chroot(2)) also, which will
return wrong results.
You will see this issue with rpm based vserver-build methods when the
tools are compiled with glibc and nscd is running.
> What changes would need to be done to make use of it
Provide a way to:
* disable dynamic libnss_* loading
* disable usage of nscd
Vserver mailing list