Re: [nssldap] release 0.2 of nss-ldapd

[Arthur de Jong <arthur [at] ch.tudelft.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Tue, 19 Jun 2007, David Houlder wrote:
> That seems like the main point of having a daemonised nss_ldap to me. 
> The current in-process implementation has side effects. Some things are 
> unavoidably shared with the calling application: file descriptors and 
> signal handling are the two most obvious ones. The file descriptor issue 
> is currently handled reasonably well I think, but it's definitely ugly.

nss-ldapd still uses file descriptors for communicating with the daemon 
(named socket) but these file descriptors are closed after each request.

If the caller messes around with file descriptors with longer-lived 
requests (eg setxxent(), getxxent(), endxxent()) he's getting what he 
deserves (which probably also goes for other nss modules).

> I think signal handling is still broken though. nss_ldap sets the 
> SIGPIPE handler to SIG_IGN on entry to an nss_ldap API call, and 
> restores it just before exit. While there's a mutex to stop other 
> threads from calling the nss_ldap API while this is happening, there's 
> nothing to stop another thread from setting the signal handler via any 
> other code path while nss_ldap is in flight. This can easily result in 
> nss_ldap stomping on an installed signal handler when it restores the 
> signal handler saved on entry.

nss-ldapd currently also does this regrettably. Before every write (which 
should happen only once for every request) SIGPIPE is set to SIG_IGN and 
the old handler is restored immediatly afterward. This uses sigaction() 
and currently fails to do any locking. Anyone with better insights in how 
to solve this?

> (Having said that, I think the current signal handling could be fixed by 
> blocking SIGPIPE with pthread_sigmask() and then "soaking up" any 
> pending SIGPIPEs before return with sigwait())

Any pointers to do this in a safe way? Also would compiling and linking 
the NSS module with -pthread cause any extra overhead for non-threaded 
applications?

- -- 
- -- arthur - arthur@ch.tudelft.nl - http://ch.tudelft.nl/~arthur --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGd9eMdW9ORzoziHIRAuSYAJ4g1emHGxZMUb0alefZooNzDHINxACePVFd
l+bcwW9NTwDX54E+i0JjSBk=
=JFaw
-----END PGP SIGNATURE-----