Bugzilla Bug 162355

Hi,

running various programs here (kcontrol and xfce-mcs-manager -version 4.2.3,
although I doubt this matters much- for instance) results in SIGPIPE
termination.

Tracing back this problem with ltrace resulted in the following interesting
excerpt:

rhuizer@mirak ~ $ ltrace -f -S xfce-mcs-manager
...
SYS_rt_sigaction(10, 0x7fff1ce28bb0, 0, 8, 0) = 0
<... sigaction resumed> ) = 0
daemon(1, 1, 0, -1, 0 <unfinished ...>
SYS_clone(0x1200011, 0, 0, 0x2b7b90c737d0, 4969) = 4970
[pid 4969] SYS_exit_group(0 <unfinished ...>
[pid 4969] +++ exited (status 0) +++
--- SIGSTOP (Stopped (signal)) ---
--- SIGSTOP (Stopped (signal)) ---
SYS_dup(7, 1, 0x7fff1ce289a0, 0x7fff1ce28868, 0x2b7b911fefa0) = 6
SYS_fcntl(6, 2, 1, 0x7fff1ce28868, 0x2b7b911fefa0) = 0
SYS_socket(2, 1, 0, 0x7fff1ce28898, 0x2b7b911fefa0) = 9
SYS_close(7) = 0
SYS_fcntl(9, 1, 1, 0x7fff1ce28878, 0x2b7b911fefa0) = 0
SYS_dup2(9, 7, 1, 0x7fff1ce28868, 0x2b7b911fefa0) = 7
SYS_fcntl(7, 2, 0, 0x7fff1ce28868, 0x2b7b911fefa0) = 0
SYS_close(9) = 0
SYS_write(7, "\025\003\001", 37) = -32
--- SIGPIPE (Broken pipe) ---
+++ killed by SIGPIPE +++

I have also provided strace output for a little bit of additional
information (the getpeername calls which ltrace does not trace, for
whatever dubious reason).

rhuizer@mirak ~ $ strace -f xfce-mcs-manager
...
rt_sigaction(SIGUSR1, {0x403190, ~[HUP INT QUIT FPE KILL USR1 USR2 TERM
CONT STOP TSTP TTOU XCPU VTALRM WINCH PWR RTMIN RT_16 RT_17 RT_18 RT_19
RT_20 RT_21 RT_22 RT_23 RT_24 RT_25 RT_26 RT_27 RT_28 RT_29 RT_30 RT_31],
SA_RESTORER|SA_RESTART, 0x2ad857d2eac0}, NULL, 8) = 0
clone(Process 4974 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x2ad8585827d0) = 4974
[pid  4973] exit_group(0)               = ?
Process 4973 detached
getsockname(7, {sa_family=AF_INET, sin_port=htons(40665),
sin_addr=inet_addr("132.229.231.14")}, [6647348608033095696]) = 0
getpeername(7, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("132.229.231.9")}, [68719476752]) = 0
fcntl(7, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
dup(7)                                  = 6
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 9
close(7)                                = 0
fcntl(9, F_GETFD)                       = 0
dup2(9, 7)                              = 7
fcntl(7, F_SETFD, 0)                    = 0
close(9)                                = 0
write(7, "\25\3\1\0 \2*\247-\330\0\345C{\0000\306\326\361\206\220"..., 37)
= -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
Process 4974 detached

Reading this it seems we have a write() system call to a descriptor
returned from socket(...), which hasn't been initialized any further, thus
triggering a SIGPIPE to be sent to the process.

Relating this information to running xfce-mcs-manager with the environment
containing LD_DEBUG=all (I will attach an excerpt later), I found that the
offending piece of code is present in libnss_ldap (version 253).

As present in ldap-nss.c:do_drop_connection()

    int dummyfd = -1, savedfd = -1;
    /*  Under OpenLDAP 2.x, ldap_set_option (..., LDAP_OPT_DESC, ...) is
        a no-op, so to shut down the LDAP connection without writing
        anything to the socket, we swap a dummy socket onto that file
        descriptor, and then swap the real fd back once the shutdown is
        done. */
    savedfd = do_dupfd (sd, -1);
    dummyfd = socket (AF_INET, SOCK_STREAM, 0);
    if (dummyfd > -1 && dummyfd != sd)
      {
        do_closefd (sd);
        do_dupfd (dummyfd, sd);
        do_closefd (dummyfd);
      }

So it is clear in this case that nss_ldap fakes the LDAP connection socket to
be a dummy socket() it just allocated. The assumption here is that no further
write() calls will be made to this dummy socket, as they would result in
SIGPIPE  errors.
However, when running over SSL, libldap (from openldap 2.3.30-r2) finally calls
SSL_shutdown, which in turn sends a shutdown notification over the socket
(SSL_CTX_set_quiet_shutdown has not been set in any way), resulting in SIGPIPE
dispatch.

I have no idea wether this should be patched in libldap or nss_ldap, but I hope
this report is enough to allow people to reproduce or understand the nature of
the problem.

With kind regards,
  -- Ronald Huizer

Created an attachment (id=107177) [edit]
LD_DEBUG=all xfce-mcs-manager output

This needs to go to upstream I think.

(In reply to comment #2)
> This needs to go to upstream I think.

Submitted the bug upstream; it's available at:
http://bugzilla.padl.com/show_bug.cgi?id=309

Any reason why you're not ignoring the SIGPIPE? I've run into this issue and
that's how I've fixed it. SSL_CTX_set_quiet_shutdown has the disadvantage of
not quite cleaning up after it's protocol, it just drops away. It's not leaking
a file descriptor in anyway I can see.

(In reply to comment #3)
> http://bugzilla.padl.com/show_bug.cgi?id=309

Has ben duped to http://bugzilla.padl.com/show_bug.cgi?id=273 which in turn
contains a patch to address the issue. Should that patch be included in
ebuilds, at least ~ARCH, before it is incorporated upstream?

257 in CVS now with the SIGPIPE fix, closing.