Msg09379.html

From Linix VServer
Revision as of 23:19, 10 November 2025 by 192.168.65.1 (talk) (Restored content from Wayback Machine)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vserver] util-vserver + dietlibc ...[edit]


  • From: Enrico Scholz
  • Date: Sat, 9 Apr 2005 03:23:06 +0200 (CEST)



sfrost@xxxxxxxxxxx (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
   library.

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
> secure?

Provide a way to:

* disable dynamic libnss_* loading
* disable usage of nscd




Enrico

Attachment: pgp2SknuueLbO.pgp
Description: PGP signature