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

[Simon Josefsson]

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.

/Simon