With shadow-4.9 I can't seem to change my password: ``` Changing password for marduk Old password: Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New password: Re-enter new password: ``` After this `passwd` hangs is using 100% CPU until I hit CTRL-C. The password is never changed. This has happened on a couple of my systems. Downgrading to shadow-4.8.1-r4 works around the issue. ``` emerge --info =sys-apps/shadow-4.9-r1 Portage 3.0.20 (python 3.8.11-final-0, default/linux/amd64/17.1/systemd, gcc-11.2.0, glibc-2.33-r5, 5.13.9-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-5.13.9-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5-2630_0_@_2.30GHz-with-glibc2.2.5 KiB Mem: 32877484 total, 6078812 free KiB Swap: 13631480 total, 13604088 free Timestamp of repository gentoo: Sat, 14 Aug 2021 11:10:10 +0000 Timestamp of repository marduk: Thu, 17 Jun 2021 00:33:45 +0000 sh bash 5.1_p8 ld GNU ld (Gentoo 2.36.1 p4) 2.36.1 app-shells/bash: 5.1_p8::gentoo dev-lang/perl: 5.34.0-r2::gentoo dev-lang/python: 3.8.11::gentoo sys-apps/baselayout: 2.7-r3::gentoo sys-apps/sandbox: 2.24::gentoo sys-devel/binutils: 2.36.1-r2::gentoo sys-devel/gcc: 11.2.0::gentoo sys-devel/gcc-config: 2.4::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.13::gentoo (virtual/os-headers) sys-libs/glibc: 2.33-r5::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://gbp/repos/blackwidow/gentoo priority: -1000 sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: False marduk location: /var/db/repos/marduk sync-type: rsync sync-uri: rsync://gbp/repos/blackwidow/marduk masters: gentoo priority: 50 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: False ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE @BINARY-REDISTRIBUTABLE" CBUILD="x86_64-pc-linux-gnu" CFLAGS=" -O2 -march=native -pipe " CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS=" -O2 -march=native -pipe " DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS=" --autounmask=n --binpkg-changed-deps --binpkg-respect-use --buildpkg --changed-deps=y --color=y --getbinpkg --jobs=4 --keep-going --oneshot --quiet-build --quiet-unmerge-warn --rebuilt-binaries=y --verbose-conflicts --with-bdeps=n " ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg cgroup config-protect-if-modified distlocks fixlafiles ipc-sandbox mount-sandbox multilib-strict network-sandbox news noinfo notitles parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms skiprocheck strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS=" --jobs=5 --load-average=5.64 --output-sync --print-directory " PKGDIR="/var/cache/binpkgs" PORTAGE_BINHOST="https://gbp/binpkgs/blackwidow/" PORTAGE_COMPRESS="" PORTAGE_COMPRESS_FLAGS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl aes amd64 asm avx ipv6 libglvnd mmx mmxext nptl pam popcnt seccomp split-usr sse sse2 sse3 sse4_1 sse4_2 ssse3 systemd threads unicode urandom xattr" ABI_X86="64" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" CURL_SSL="openssl" ELIBC="glibc" GRUB_PLATFORMS="pc" INPUT_DEVICES="libinput" KERNEL="linux" LUA_SINGLE_TARGET="lua5-4" NGINX_MODULES_HTTP="addition auth_basic autoindex fancyindex gzip headers_more proxy rewrite sub upload uwsgi" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python3_8" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" USERLAND="GNU" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS, RUSTFLAGS ================================================================= Package Settings ================================================================= sys-apps/shadow-4.9-r1::gentoo was built with the following: USE="acl (split-usr) xattr -audit -bcrypt -cracklib -nls -pam (-selinux) -skey -su" ABI_X86="(64)" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg config-protect-if-modified distlocks fixlafiles multilib-strict news noinfo notitles parallel-fetch preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms skiprocheck strict unknown-features-warn unmerge-logs unmerge-orphans xattr" ```
Is it possible for you to run strace on the process while it's looping?
(In reply to Sam James from comment #1) > Is it possible for you to run strace on the process while it's looping? I did run strace. I don't see anything looping, actually. The last two calls are to getrandom() and after that no more output from strace.
Hopefully I've redacted everything sensitive. The first line is when it reads the current password. The last two lines are after I hit CTRL-C after waiting a while. ``` read(3, "xxxxxxxxxx", 4096) = xx write(3, "\n", 1) = 1 ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 close(3) = 0 openat(AT_FDCWD, "/etc/login.defs", O_RDONLY) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=13608, ...}, AT_EMPTY_PATH) = 0 read(3, "#\n# /etc/login.defs - Configurat"..., 4096) = 4096 read(3, "ou have a write(1) program which"..., 4096) = 4096 read(3, "thm. Default is \"no\".\n#\n# Note:"..., 4096) = 4096 read(3, "will make sure that\n# groups nev"..., 4096) = 1320 read(3, "", 4096) = 0 close(3) = 0 write(1, "Enter the new password (minimum "..., 119) = 119 openat(AT_FDCWD, "/dev/tty", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3 ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig icanon -echo ...}) = 0 newfstatat(3, "", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x5, 0), ...}, AT_EMPTY_PATH) = 0 ioctl(3, TCGETS, {B38400 opost -isig icanon -echo ...}) = 0 write(3, "New password: ", 14) = 14 read(3, "xxxxxxxxxxxx", 4096) = xx write(3, "\n", 1) = 1 ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 close(3) = 0 openat(AT_FDCWD, "/dev/tty", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3 ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig icanon -echo ...}) = 0 newfstatat(3, "", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x5, 0), ...}, AT_EMPTY_PATH) = 0 ioctl(3, TCGETS, {B38400 opost -isig icanon -echo ...}) = 0 write(3, "Re-enter new password: ", 23) = 23 read(3, "xxxxxxxxxxxx", 4096) = xx write(3, "\n", 1) = 1 ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 close(3) = 0 getrandom("\x00\x00\x00\x00\x00\x00\x0\x00", 8, 0) = 8 getrandom("\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 15, 0) = 15 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} --- +++ killed by SIGINT +++ ```
Did getrandom() really return 23 bytes equal to \x00? Or did you "redact" the real value?
(In reply to Mike Gilbert from comment #4) > Did getrandom() really return 23 bytes equal to \x00? Or did you "redact" > the real value? Yes, sorry. I replaced the real values with 0s.
It seems to be looping in userspace, so you'll probably need to fire up gdb to diagnose it. Attach gdb to the passwd process, and then hit Ctrl-C in the terminal running passwd. You should be able to get a backtrace at that point.
Not sure how useful this is. I'm not very good with gdb: ``` (gdb) n 155 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 156 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 157 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 158 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 159 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 160 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 125 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 126 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 127 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 128 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 129 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 130 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) n 131 in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/lib/alg-sha512.c (gdb) q ``` I tried rebuilding libxcrypt with `CFLAGS="-g" FEATURES="nostrip"` but that's still all I get.
I can reproduce the issue by setting USE=-pam locally.
(In reply to Mike Gilbert from comment #8) > I can reproduce the issue by setting USE=-pam locally. I could enable pam. I disabled pam a while back because I found cracklib annoying and pam requires cracklib.
Found an interesting call: #5 0x0000558459bfa386 in pw_encrypt (clear=0x7ffeab575cd0 "xxxxxxxx", salt=0x7f6b1641c160 "$6$rounds=999999999$xCbkxOhn8MB1Fz2a") at encrypt.c:48 The "rounds=999999999" might explain why it is taking so long to compute the SHA512 hash.
(In reply to Albert W. Hopkins from comment #9) > I could enable pam. I disabled pam a while back because I found cracklib > annoying and pam requires cracklib. pam does not require cracklib. It was an optional dependency, and it has been replaced by passwdqc. If you found cracklib annoying, you probably want to disable the passwdqc USE flag on sys-auth/pambase.
Un-commenting this line in /etc/login.defs fixes the original issue: SHA_CRYPT_MAX_ROUNDS 5000 I think there is a bug in the SHA_get_salt_rounds function, causing it to default to 999999999 instead of 5000.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=facfcc2e69ac04433cb0b9b31b755d9e9fb20b2b commit facfcc2e69ac04433cb0b9b31b755d9e9fb20b2b Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-08-15 00:46:26 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-08-15 00:46:26 +0000 sys-apps/shadow: fix SHA hash behavior with USE=-pam Closes: https://bugs.gentoo.org/808195 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/shadow/files/shadow-4.9-SHA-rounds.patch | 57 ++++++++++++++++++++++ .../{shadow-4.9-r1.ebuild => shadow-4.9-r2.ebuild} | 1 + 2 files changed, 58 insertions(+)
