Я становлюсь страшным sudo: must be setuid root
ошибка, даже если исполняемый файл в /usr/bin/sudo
имеет право собственности root:root
и режим 4755 (-rwsr-xr-x
). /etc/sudoers
это режим 440. Мой пользователь находится в sudoers со всеми соответствующими настройками. Я очистил и переустановил пакет, но безрезультатно.
Я изначально не настраивал эту машину; его содержание по умолчанию упало на меня. Возможно ли, что это поведение является взаимодействием с PAM, и если да, как его исправить? На машине установлено ядро SMP Debian squeeze 2.6.26-2-686. Ничего не написано о невыполнении /var/log/auth.log
так что перед этим нужно выручить.
ОБНОВЛЕНИЕ: вот sudoers (с удаленным множеством лишних строк комментариев), но я почти уверен, что проблема не в этом.
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:\
/usr/bin:/sbin:/bin"
# Host alias specification
# User alias specification
User_Alias SUDOERS=david
Defaults:SUDOERS !lecture,!authenticate
# User privilege specification
root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
SUDOERS ALL=(ALL:ALL) ALL
Да, я знаю, что это слишком небрежно. Подтяну, когда заработает. Насколько я могу судить, он даже не доходит до стадии чтения этого файла, а умирает, когда сам процесс sudo пытается повысить свой идентификатор пользователя. Почти идентичная установка безупречно работает на нескольких (> 10) других машинах, поэтому я думаю, что это должна быть внешняя конфигурация, которая вызывает сбой.
Благодаря MadHatter я нашел решение. Файловая система была создана как один большой корневой раздел (не мной!) С / usr, / var, / home и т. Д. Просто как подкаталоги. По какой-то причине он также был установлен без жидкости, предположительно в результате ошибочной попытки обеспечения безопасности. Я продвигаю это как ответ, чтобы он быстрее проявился для всех, кто страдает той же проблемой. Я должен был проверить параметры монтирования, но не подумал об этом, так как это такая глупая ситуация.