Bug#566351: libgcrypt11: should not change user id as a side effect

Simon Josefsson simon at josefsson.org
Wed Jan 27 09:44:39 CET 2010

Ansgar Burchardt <ansgar at 43-1.org> writes:

> Werner Koch <wk at gnupg.org> writes:
>> On Mon, 25 Jan 2010 16:13, ansgar at 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.


More information about the Gcrypt-devel mailing list