Woohoo! I nailed it.... (Was: Another showstopper in 2.2.5)

[Fredrik Ohrn]

On Fri, 23 Aug 2002, Wade Turland wrote:

> Hi all
> 
> We seem to have similar problems, although no report of corruptions yet,
> only slow connections and saves when the system load increases (> 300
> smbds). I have seen several log entries complaining of broken pipes:
> 
> [2002/08/20 11:17:00, 0] lib/util_sock.c:get_socket_addr(1012)
>   getpeername failed. Error was Transport endpoint is not connected
> [2002/08/20 11:17:00, 0] lib/util_sock.c:write_socket_data(499)
>   write_socket_data: write failure. Error = Broken pipe
> [2002/08/20 11:17:00, 0] lib/util_sock.c:write_socket(524)
>   write_socket: Error writing 4 bytes to socket 5: ERRNO = Broken pipe
> [2002/08/20 11:17:00, 0] lib/util_sock.c:send_smb(704)
>   Error writing 4 bytes to client. -1. (Broken pipe)
> 
> We also use nss_ldap (105) from PADL, but according to a post from Luke
> Howard, it was fixed in 181:
> http://www.netsys.com/nssldap/2002/02/msg00100.html
> 

Samba blocks sigpipe using sigprocmask().

The problem is that the fix in 181 uses signal(SIGPIPE, SIG_IGN) to 
ignore it, this has the implicit effect of unblocking the signal if it was 
blocked with sigprocmask. On exit nss_ldap cleans up by resetting the 
signal to SIG_DFL and from now on Samba is vulnerable.

The next version (200) will use sigprocmask instead and play nice with 
Samba.


Be glad you are still using 105 else your samba server would have come 
crashing down like a house of cards... Instead of those broken pipe 
messages you see in the log the smbds would have been killed.

Why you get them in the first place is another matter, for some (unknown) 
reason your clients (or whatever it is on the other end of that socket) 
suddenly drops the connection.



> We keep /etc/passwd *mostly* populated but locked to save the DS from
> searching through 58000 user accounts when a program calls getpw*** so
> perhaps corruption occurs infrequently enough that people don't report it.
> 
> So what version of nss_ldap do you use and do we have the same problem?
> 


We are currently using 198 since we got bitten by another bad interaction 
between nss_ldap and LPRng in versions <= 186.


/Fredrik

-- 
   "It is easy to be blinded to the essential uselessness of computers by
   the sense of accomplishment you get from getting them to work at all."
                                                   - Douglas Adams

Fredrik Öhrn                               Chalmers University of Technology
ohrn at chl.chalmers.se                                                  Sweden