Ansgar Burchardt <ans...@43-1.org> writes: > Werner Koch <w...@gnupg.org> writes: > >> On Mon, 25 Jan 2010 16:13, ans...@43-1.org said: >> >>> Yes, it is even quite simple to write such an application: Just call >>> getgroups(), getpwent(), ... on a system that uses LDAP. If there is no >>> caching daemon like nscd running, the application will use libnss-ldap >>> (via glibc's Name Service Switch) which can in turn use gnutls. >> >> That is a broken design. glibc should never ever allow suid processes >> to run code from external services it is not 100% sure they are clean. >> I guess libnss_files and the other standard ones might be fine, but LDAP >> or even LDAPS are very problematic. Such code belongs into a separate >> process and not into the one of an arbitrary - possible suid - >> application. > > It can run in a separate process if nscd (glibc's name service caching > daemon) is running. But if nscd is not installed or not running for > some reason, there is not much to do except doing the query in the same > process.
Why can't the system call fail in that situation? > There are enough sensible reasons for an application using gcrypt only > indirectly (eg. applications using gnutls should not need to care which > cryptographic library is used by it, more so for applications that only > use a library like libcurl that uses gnutls, but can also use OpenSSL). I agree here though. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
