Re: [nssldap] release 0.2 of nss-ldapd

[David Houlder <david.houlder@anu.edu.au>]

Howard Chu wrote:
> Andreas Hasenack wrote:
...
> > - one also doesn't have to worry about filedescriptors from the
> >   application, like closing the wrong ones, etc
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.
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.
> Depends on your communication method with the daemon. That IPC is still 
> vulnerable.
Ideally the connection could be set up and torn down on each nss_ldap 
API call. I haven't timed unix domain sockets, but presumably they're 
much quicker to connect and close than TCP across a network. Even if 
they're too slow and some sort of shared memory were used instead, 
there's a difference between the code being vulnerable to, say, stray 
pointers and the current situation where nss_ldap is modifying state 
that is defined to be global to the process (signal handlers, file 
descriptors).
e.g. If I wrote some application that broke the proposed daemonised 
nss_ldap because a stray pointer of mine wrote garbage into nss_ldap's 
shared memory buffer, I'd say it was my fault. If I wrote an application 
that installs a signal handler, and the current nss_ldap stomps on it as 
a side effect, I'd say it's nss_ldap's fault.
(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())
cheers
David.
--
   David.Houlder@anu.edu.au         ANU Supercomputer Facility
   Phone: +61 2 6125 0578           and APAC National Facility
   Fax:   +61 2 6125 8199           Leonard Huxley Bldg (No. 56)
                                    Australian National University
                                    Canberra, ACT, 0200, Australia