Timo Sirainen:
> On 27.4.2011, at 0.53, Victor Duchovni wrote:
>
> >> Just wondering: Is it really the nss-ldap code that is buggy or just
> >> the libc's getpwnam() call that is fundamentally broken? I recently
> >> changed Dovecot to use getpwnam_r() instead, since it allows proper
> >> error checking.
> >
> > Most likely a combination of both. It is not, for example, clear which
> > error returns from getpwnam_r() indicate a transient error, and which
> > "entry not found". This is an API problem.
>
> It is clear. getpwnam_r() returns 0 both on success and "user not
> found", you just need to check if the result is NULL or not. If
> it returns anything else than 0 it's a transient error. If the
> NSS code internally messes this up, that's its fault then. But I
> think getpwnam_r() API is fine.
Just checking: whose getpwnam_r() API are you talking about?
I looked at some manpages and found that vendors have been changing
their getpwnam() and getpwnam_r() error reporting semantics over
time.
Just because a system has getpwnam_r(), that does not mean it works
like your API; and on some systems, getpwnam() does report errors
via errno (e.g. FreeBSD8), whereas the original UNIX getpwnam()
never returned for transient errors, because all reads were from
local files.
Wietse
