PAM: ошибка аутентификации, с действительным паролем

команда

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

Как сейчас, каждый экран блокировки не позволит мне «разблокировать» (экран блокировки KDE и i3lockт. Д.).

Если я начну i3lockкак sudo, то смогу правильно ввести пароль root, чтобы разблокировать экран. Однако, если я запускаю его как обычный пользователь, и я не могу использовать пароль обычного пользователя или root для разблокировки.

Вот мой конфиг PAM для 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

Беговые ls -l /etc/passwd /etc/shadow /etc/groupшоу

-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

Это свежая установка Arch, поэтому я не думаю, что конфигурация слишком шаткая. Что я должен искать, чтобы отладить это?

Беговые ls -l /sbin/unix_chkpwdшоу

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

pam

— Пол Кнопф
источник

Вы имеете учетную запись пользователя pknopfв вашей /etc/passwd, и т.д., и он может войти?

— roaima

Моя учетная запись находится в / etc / passwd.

— Пол Кнопф

Я могу «pamtester auth pknopf authenticate» с (запущенным от имени) пользователем root, но не с пользователем pknopf.

— Пол Кнопф

Результат ls -l /sbin/unix_chkpwdдобавил к вашему вопросу, пожалуйста.

— Ройма

Обновленный вопрос, чтобы включить вывод.

— Пол Кнопф

Ответы:

Ваша установка системы, кажется, сломана. По какой-то причине файл /sbin/unix_chkpwdпотерял привилегированные биты, которые я ожидал увидеть.

Исправьте разрешения, выполнив следующую команду от имени пользователя root:

chmod u+s /sbin/unix_chkpwd

И убедитесь, что разрешения теперь следующие (см. sБит в разрешениях пользователя):

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

В моем дистрибутиве Raspbian разрешения установлены немного по-другому (и более строго). Если описанное выше изменение не работает, тщательно измените разрешения для этих двух файлов и посмотрите, поможет ли это (имя группы не имеет большого значения, если оно одинаково в обоих случаях):

-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

— roaima
источник

Это как моя проблема. Это был результат того, что Docker лишил эту привилегию. github.com/moby/moby/issues/36239

— Пол Кнопф

На моем компьютере с Debian мне пришлось добавить пользователя exim4 в shadowгруппу.

usermod -a -G shadow Debian-exim

PAM: В системах Debian модули PAM работают от имени того же пользователя, что и вызывающая программа, поэтому они не могут делать ничего, что вы не можете делать сами, и, в частности, не можете получить доступ к / etc / shadow, если пользователь не находится в тени группы. - Если вы хотите использовать / etc / shadow для SMTP AUTH в Exim, вам нужно запустить exim в качестве тени группы. Только exim4-daemon-heavy связан с libpam. Вместо этого мы предлагаем использовать saslauthd.

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

— Даниэль Соколовский
источник