Типичное отсутствие доступа к хэшу пароля в теневом файле может сделать этот запрос проблематичным для случайной пользовательской программы, использующей системную базу данных паролей, поскольку sudo
и chsh
и подобные программы обычно имеют установленный бит setuid, так что они запускаются от имени root
и могут получить доступ к теневому файлу.
[jdoe@centos ~]$ id -u
1001
[jdoe@centos ~]$ perl -E 'say for getpwuid(1001)'
jdoe
x
1001
1001
/home/jdoe
/bin/bash
[jdoe@centos ~]$ sudo perl -E 'say for getpwuid(1001)'
jdoe
$6$P1jejm1i$bo02c/...
1001
1001
/home/jdoe
/bin/bash
[jdoe@centos ~]$
Как только программа может получить хэш пароля пользователя (из системной базы данных или из другого источника, это отредактированный $6$P1jejm1i$bo02c/...
бит в приведенном выше выводе), традиционного вызова crypt(3)
должно быть достаточно для проверки пароля.
Программа, запрашивающая пароль, может также захотеть предотвратить дампы ядра, заблокировать себя в памяти, очистить различные биты памяти после этого, игнорировать различные сигналы, а также пройти еще более строгую проверку, если она запущена в setuid, в дополнение к тому, чтобы не повторять пароль. OpenBSD упрощает некоторые из этих шагов с помощью readpassphrase(3)
, хотя другие ОС не так сильно: getpass(3)
помечен как LEGACY...