su к корню перестал работать когда заблокированный пользователь root?
Адресной и маршрутной информацией может быть использование установки ip. DNS установлен в файле /etc/resolv.conf.
ip addr add 172.16.5.23
ip route add 172.16.0.0/16 via 172.16.1.1
echo -e "nameserver 172.16.1.10\nnameserver 172.16.1.250" > /etc/resolv.conf
Создайте файл с именем «~/.su -to -rootrc» с содержимым «SU _TO _ROOT _SU="sudo"».
Пример:
echo 'SU _TO _ROOT _SU="sudo"'> ~/.su -to -rootrc
Или создайте его для всей системы в /etc. su -to -root без этого rc-файла всегда пытается использовать su, что не работает с заблокированной корневой учетной записью. Если вы создаете файл rc, вместо этого он использует sudo, и все в порядке.
Это кажется сценарием /usr/bin/su-to-root сравнивает euid пользователя, работающего su-to-root к euid или корня учетной записи (значение по умолчанию) или указанной пользователями учетной записи:
euid=$(id -u)
privid=$(id -u $PRIV)
if test "$euid" = "$privid"; then
sh -c "$COMMAND"
Если соответствие euid, su к корню пропускает команда выполнений и аутентификация sh -c /usr/sbin/synaptic сразу, пропуская gksu/kdesu/ktsuss/sux/and так дальше.
Так, это кажется /usr/bin/su-to-root предполагает, что вызывающий абонент имеет полномочия пользователя root и не проходит проверку подлинности..., который, кажется, представляет допустимое предположение в Debian.
Как обходное решение, я изменил команду пункта меню Debian от su-to-root -X -p "user" -c /usr/sbin/synaptic кому: gksu -S /usr/sbin/synaptic.
От человека gksu:
- sudo-режим,-S: Вынудите gksu использовать sudo (1) в качестве его бэкенда для того, чтобы запустить программы.
Это, кажется, вызывает sudo, который представляет то, что я хочу. Синаптический Диспетчер пакетов проходит проверку подлинности в случае необходимости.