9

Command

pamtester -v auth pknopf authenticate
pamtester: invoking pam_start(auth, pknopf, ...)
pamtester: performing operation - authenticate
Password:
pamtester: Authentication failure

journctl

Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: check pass; user unknown
Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: password check failed for user (pknopf)
Feb 06 13:22:17 PAULS-ARCH pamtester[31997]: pam_unix(auth:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  user=pknopf

As it stands right now, every lock screen will prevent me from "unlocking" (KDE lock screen, i3lock, etc).

If I start i3lock as sudo, I can then properly type in the root password to unlock the screen. However, if I run it as normal user, and I can't use normal user or root password to unlock.

Here is my PAM config for i3lock.

#
# PAM configuration file for the i3lock screen locker. By default, it includes
# the 'system-auth' configuration file (see /etc/pam.d/login)
#
auth include system-auth

Running ls -l /etc/passwd /etc/shadow /etc/group shows

-rw-r--r-- 1 root root 803 Feb 6 14:16 /etc/group
-rw-r--r-- 1 root root 1005 Feb 6 14:16 /etc/passwd
-rw------- 1 root root 713 Feb 6 14:16 /etc/shadow

This is a fresh install of Arch, so I don't think the configuration is too wonky. What should I be looking for to debug this?

Running ls -l /sbin/unix_chkpwd shows

-rwxr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd
  • You've a user account pknopf in your /etc/passwd, etc., and it can log in? – roaima Feb 6 '18 at 23:45
  • My account is in /etc/passwd. – Paul Knopf Feb 7 '18 at 0:26
  • I can "pamtester auth pknopf authenticate" with (running as) root user, but not with pknopf user. – Paul Knopf Feb 7 '18 at 7:07
  • Result of ls -l /sbin/unix_chkpwd added to your question, please. – roaima Feb 7 '18 at 8:45
  • Updated question to include the output. – Paul Knopf Feb 7 '18 at 14:46
11

Your system installation appears to be broken. For some reason, the file /sbin/unix_chkpwd has lost the privilege bits I would expect to see.

Fix the permissions by running the following command as root:

chmod u+s /sbin/unix_chkpwd

And verify the permissions are now as follows (see the s bit in the user permissions):

-rwsr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd

On my Raspbian distribution the permissions are set slightly differently (and more restrictively). If the change described above does not work, carefully change the permissions on these two files and see if this helps (the group name does not matter too much as long as it's the same in both cases):

-rw-r----- 1 root shadow  1354 Dec  6 13:02 /etc/shadow
-rwxr-sr-x 1 root shadow 30424 Mar 27  2017 /sbin/unix_chkpwd
4

On a Debian machine, in my case I had to add exim4 user to the shadow group.

usermod -a -G shadow Debian-exim

PAM: On Debian systems the PAM modules run as the same user as the calling program, so they cannot do anything you could not do yourself, and in particular cannot access /etc/shadow unless the user is in group shadow. - If you want to use /etc/shadow for Exim's SMTP AUTH you will need to run exim as group shadow. Only exim4-daemon-heavy is linked against libpam. We suggest using saslauthd instead.

http://lira.no-ip.org:8080/doc/exim4-base/README.Debian.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.