Date: Thu, 28 May 2020 15:12:47 -0700
From: Keith Thompson <keith.s.thomp...@gmail.com>
Message-ID:
<caahpripmadctyqlkygqa6fm_ayvqkfn_f7p1qzkoqj-2-g1...@mail.gmail.com>
| Program received signal SIGSEGV, Segmentation fault.
| 0x00007ffff777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
| (gdb) where
| #0 0x00007ffff777eddb in ?? () from
/lib/x86_64-linux-gnu/libnss_systemd.so.2
| #1 0x00007ffff77721c8 in ?? () from
/lib/x86_64-linux-gnu/libnss_systemd.so.2
| #2 0x00007ffff7773009 in ?? () from
/lib/x86_64-linux-gnu/libnss_systemd.so.2
| #3 0x00007ffff77883e7 in _nss_systemd_getpwnam_r () from
| /lib/x86_64-linux-gnu/libnss_systemd.so.2
| #4 0x00007ffff7e53f03 in __getpwnam_r (name=name@entry=0x555555722368
| "nosuchuser", resbuf=resbuf@entry=0x7ffff7f5e140 <resbuf>,
| buffer=0x555555777808 "systemd-coredump",
| buflen=buflen@entry=1024, result=result@entry=0x7fffffffddb0) at
| ../nss/getXXbyYY_r.c:315
| #5 0x00007ffff7e537ec in getpwnam (name=0x555555722368 "nosuchuser")
| at ../nss/getXXbyYY.c:134
Since that shows the crash is inside getpwnam() (or more correctly, the
NSS finctions it calls) and also shows that the correct arg was passed to
getpwnam(), it is unlikely to be a bash bug.
This one needs to be reported to whoever supplies the libc you're using,
and they will want to know what is in your nss config fle (at least the
entry for "passwd").
kre
ps: for what it is worth, this doesn't fail on NetBSD either - where I
have the NSS configured as
passwd: files
