Hi, I noticed that nginx's PAM auth module wasn't working so I straced it and noticed that it could not access shadow: [pid 2677] openat(AT_FDCWD, "/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) Logs contain the following entry: unix_chkpwd[2677]: check pass; user unknown This is easy to reproduce with echo -e "<pwd>\0" | /sbin/unix_chkpwd <username> nonull The unix_chkpwd binary has the right permissions: # ls -l /sbin/unix_chkpwd -rws--x--x 1 root root 35216 Dec 8 22:15 /sbin/unix_chkpwd The following code is the cause of the problem, it forces unix_chkpwd to setuid to the calling user (nginx in my case): https://github.com/linux-pam/linux-pam/blob/3b77a78d575b8ab56bb0e828499df328d55c925f/modules/pam_unix/unix_chkpwd.c#L139 https://github.com/linux-pam/linux-pam/commit/6ccbba1cf178e9de46347e2f9df76f69aebcec20 Debian worked around it at the time: https://gitlab.gnugen.ch/fvessaz/pkg-pam/commit/9c123bbb6b25524e768b54506117a9acfe82409e Nowadays, it looks like Debian has setgid set for the binary but not setuid. Archlinux has both. Wth setgid, the additional problematic setuid call doesn't prevent unix_chkpwd from working any more so perhaps we could simply change the perms from 4711 to 2711?
Yes, we are using filecaps, so if you disable this ist is your responsibility
(In reply to Mikle Kolyada from comment #1) > Yes, we are using filecaps, so if you disable this ist is your responsibility I didn't disable it myself, the systemd stage3 has it disabled: https://gitweb.gentoo.org/proj/releng.git/commit/?id=6ca51d9ebebcf52984a80a6db95ab8623d95d1f3
(In reply to Louis Sautier (sbraz) from comment #2) > (In reply to Mikle Kolyada from comment #1) > > Yes, we are using filecaps, so if you disable this ist is your responsibility > > I didn't disable it myself, the systemd stage3 has it disabled: > https://gitweb.gentoo.org/proj/releng.git/commit/ > ?id=6ca51d9ebebcf52984a80a6db95ab8623d95d1f3 then blame them
