rpc.yppasswdd dumps core

[Patrick Welche]

Note this is rpc.yppasswdd and not yppasswd (The first hit in "Ask Ubuntu" gets confused.)

As root on the nis master:

# yppasswd noone
Changing NIS account information for noone on server.nospam.com.
Please enter root password:
Changing NIS password for noone on server.nospam.com.
Please enter new password:
Please retype new password:
RPC: Unable to receive
The NIS password has not been changed on server.nospam.com.

apport.log:ERROR: apport (pid 913) Thu Sep 29 14:37:56 2016: wrote report /var/crash/_usr_sbin_rpc.yppasswdd.0.crash

kern.log:Sep 29 14:37:55 eagle kernel: [186749.744995] rpc.yppasswdd[1986]: segfault at 0 ip 00007fe0e49feb5a sp 00007ffc14ffd8f8 error 4 in libc-2.23.so[7fe0e4960000+1c0000]

ProblemType: Crash
Architecture: amd64
Date: Thu Sep 29 14:37:56 2016
DistroRelease: Ubuntu 16.04
ExecutablePath: /usr/sbin/rpc.yppasswdd
ExecutableTimestamp: 1449064880
ProcCmdline: /usr/sbin/rpc.yppasswdd -D /var/yp/etc -e chsh

Signal: 11
Uname: Linux 4.4.0-38-generic x86_64

nis/xenial,now 3.17-34ubuntu3 amd64 [installed]
  clients and daemons for the Network Information Service (NIS)

[Christian Ehrhardt  (paelzer)]

Hi,
I have worked on a similar issue regarding the non <rpc.> variant of yppasswd.
All I had back then as repro setup worked fine, you can see what I usually used as quick repro in the SRU template of bug 1204530.

I wonder if you could share how one needs to configure/call yppasswd to reproduce your issue?

[Patrick Welche (prlw1)]

When creating a new nis user, we add a line of the form:

$NEWNAME:x:$NEWUID:1000:$DESC:/home/$NEWNAME:/bin/bash

note the x. Before updating to ubuntu 16, we would then run yppassswd to change the password.

We found a work around: in ubuntu 16, if you replace the x with a password, then (restart rpc.yppasswdd after it crashed) the password change works. (no shadow file in operation)

[Christian Ehrhardt  (paelzer)]

Hi,
given your feedback I was continuing to reproduce with:
 * new Xenial container
 * install nis
 * avoid known bug 1558196
    $ sudo /bin/systemctl add-wants multi-user.target rpcbind.service
 * Config in /etc/default/nis: NISSERVER=master
 * Config in /etc/yp.conf: ypserver 127.0.0.1
 * Initialize with
     $ sudo /usr/lib/yp/ypinit -m
     $ service ypbind restart
     $ service rpcbind restart
 * Test if your config works
     $ ypcat passwd
     should show something like
     ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
 * Trigger the bug
     $ yppasswd -p ubuntu
         Changing NIS account information for ubuntu on xenial-test.
         Please enter root password:
         Changing NIS password for ubuntu on xenial-test.
         Please enter new password:
         Please retype new password:
         RPC: Unable to receive
         The NIS password has not been changed on xenial-test.
      This pretty much looks like your issue I think
  * I find this in the dmesg
    [20235.104479] rpc.yppasswdd[18166]: segfault at 0 ip 00007fe1eb41cb5a sp 00007ffcf114a6d8 error 4 in libc-2.23.so[7fe1eb37e000+1c0000]

Please note that I was unable to use your:
     "$NEWNAME:x:$NEWUID:1000:$DESC:/home/$NEWNAME:/bin/bash"
     I can't add it to the dbm files and if I do so to /etc/passwd yp just never recognizes it as valid user.
     But since the auto-inituali user being ubuntu is enough to trigger that is ok.

I'm checking Yakkety and Debian next to get a feeling where things got broken, updating soon I hope.

[Christian Ehrhardt  (paelzer)]

Yakkety has the same version still, so no wonder it applies there as well:
[21225.454247] rpc.yppasswdd[23877]: segfault at 0 ip 00007fb4ab16f5ca sp 00007ffe262e6588 error 4 in libc-2.24.so[7fb4ab0cf000+1bd000]

Debian needs to add a user before ypinit as its LXD images have no non-root default user
 $ useradd test
But other than that this applies to Debian as well leading to:
rpc.yppasswdd[26200]: segfault at 0 ip 00007fef59ccb34a sp 00007ffc225f75a8 error 4 in libc-2.24.so[7fef59c3c000+195000]

Since Debian-sid just recently updated to upstream nis I have to assume that this is an upstream issue or of the way Debian & Ubuntu are integrating it.

[Christian Ehrhardt  (paelzer)]

After the former setup a loop like this can reliably trigger the bug:

#!/bin/bash
while /bin/true
do
    lxc exec yakkety-test service rpcbind restart
    lxc exec yakkety-test service ypbind restart
    cat << EOF | lxc exec yakkety-test -- yppasswd -p ubuntu

ubuntu
ubuntu
EOF
done

At least it seems to hit the same spot all the time:
[22151.939991] rpc.yppasswdd[2040]: segfault at 0 ip 00007fc59f8895ca sp 00007fff97fa37f8 error 4 in libc-2.24.so[7fc59f7e9000+1bd000]
[22379.086169] rpc.yppasswdd[2711]: segfault at 0 ip 00007f9709fb55ca sp 00007ffc68830b08 error 4 in libc-2.24.so[7f9709f15000+1bd000]
[22424.338326] rpc.yppasswdd[2913]: segfault at 0 ip 00007f93782a75ca sp 00007ffe87898618 error 4 in libc-2.24.so[7f9378207000+1bd000]
[...]

[Christian Ehrhardt  (paelzer)]

The error itself is in an asm piece of glibc

Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31 movdqu (%rdi), %xmm1

For the time being I'd more expect this to be an error in nis than in glibc.
Well maybe an incompatibility of nis with recent glibc versions.

Despite installing all debug symbols I could grab I only see the RPC hanlding bits of glibc, followed by some unknowns leading to a crash in the sse2 glibc parts.
The entry point is where it receives the RPC, but things are too unreadable for now - need less optimized and non stripped code of nis ...

[Christian Ehrhardt  (paelzer)]

NIS has no debug symbols and it seems currently is FTBFS.
I'll need those symbols and non optimized nis to continue debugging where the error is coming from.

Marking as triaged and adding to backlog of the server Team.
Assigning to me for now until I debugged or gave up :-)

[Christian Ehrhardt  (paelzer)]

Further debugging blocked by bug 1630462 for now.

[Patrick Welche (prlw1)]

On Tue, Oct 04, 2016 at 12:19:04PM -0000, ChristianEhrhardt wrote:
> Please note that I was unable to use your:
> "$NEWNAME:x:$NEWUID:1000:$DESC:/home/$NEWNAME:/bin/bash"
> I can't add it to the dbm files and if I do so to /etc/passwd yp just never recognizes it as valid user.

Yes you did ;-) You used variable NEWNAME set to "ubuntu", variable NEWUID set
to 1000, and variable DESC set to "Ubuntu".

Cheers,

Patrick

[Christian Ehrhardt  (paelzer)]

I have to excuse I wasn't able to follow up on that, but also see no time soon to do so.
Yet since I wanted to be honest I thought I should state that here now that it is idle for quite a while :-/