43

Я работаю с участником службы поддержки для продукта, и он настаивает на том, что мне нужно быть пользователем root, чтобы установить серию исправлений, и что sudo не будет работать; он не приводит причину, но кажется очень твердым в своих убеждениях. Просматривая Superuser, я не могу определить любую возможную причину этого, и в подтверждение, когда я запускаю:

sudo -l

Я получил:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Как я понимаю, получение доступа от команды Linux/server для получения прав root не является непосредственным процессом, поэтому я бы предпочел установить их самостоятельно.

Есть ли практическая причина, по которой sudo будет вести себя иначе, чем root, при установке программного обеспечения на сервер?

5 ответов5

33

Это сильно зависит от того, как вы называете свою программу с помощью sudo или su .
Например, в системе, в которой я нахожусь в данный момент:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1] 

Где [1] =/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Env = переменные среды сбрасываются для 1 и 5, взяты из $ USER в 2,3,4.

Таким образом, скрипт или программа, запускаемая с другой опцией, может видеть разные $PATH , $HOME , его оболочка может читать разные переменные .bashrc , .profile и Environment. Он читает файл, связанный с $HOME . Каждый пользователь может изменить свое окружение по-своему (переменные, $PATH , .bashrc, .profile, .bash_profile, псевдоним ...). В частности, у пользователя может быть другой порядок каталогов в его $PATH и, как следствие, сценарий может выполнить команду, например, в /home/$USER/bin вместо той, которая находится в пути, ожидаемом от root.

Вы можете запустить программу с помощью sudo -i поскольку вы вошли в систему как пользователь root с помощью su -, но у вас может быть другое поведение, если вы запускаете ее с помощью sudo MyCommand или su -c MyCommand .


От man su:

В части описания:
Текущее окружение передается новой оболочке. Значение $ PATH сбрасывается в /bin:/usr /bin для обычных пользователей или /sbin:/bin:/usr /sbin:/usr /bin для суперпользователя
...
В разделе опций:
-, -l, --login
Создайте среду, аналогичную той, которую пользователь ожидал бы при непосредственном входе в систему.

От человека sudo

-i, --login
Запустите оболочку, указанную в записи базы данных паролей целевого пользователя, в качестве оболочки входа в систему. Это означает, что специфичные для входа файлы ресурсов, такие как .profile или .login, будут прочитаны оболочкой. Если указана команда, она передается в оболочку для выполнения через параметр оболочки -c. Если команда не указана, выполняется интерактивная оболочка. sudo пытается перейти в домашний каталог этого пользователя перед запуском оболочки. Команда запускается в среде, аналогичной той, которую пользователь получит при входе в систему. В разделе «Командная среда» руководства sudoers(5) описано, как параметр -i влияет на среду, в которой выполняется команда, когда используется политика sudoers.

22

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

В самом деле, существует способ различить разницу между программой, запущенной с правами root и программой, запускаемой с использованием sudo - с использованием getuid и geteuid - но это надуманный прием. Почему патч-система делает это?

7

Есть несколько различий, если вы получаете корневую оболочку, как указывает @Hastur.

Если вы не получаете корневую оболочку, то есть больше различий. Участник поддержки может иметь опыт попыток сделать что-то вроде sudo patch -p0 < /root/patch.file где patch запускается от имени root, но < (получение из файла) - нет.

1

Я считаю, что при использовании доступа sudo создается файл журнала, однако при запуске напрямую через root-доступ его нет.

0

Это зависит от того, насколько хорошо вы хотите получить доступ с правами root. Если у вас есть несколько пользователей, которые выполняют разные задачи в системе, то sudo будет более идеальным. Одним из примеров, который я часто использую, является необходимость перезапустить приложение или базу данных. Безопасность всегда лучше делать с наименьшими привилегиями. Я использую группы и разрешаю только этим группам выполнять явные действия. Хорошая книга, описывающая этот процесс, - «Мастерство Судо: Контроль доступа пользователей для реальных людей». На самом деле это хорошая книга о sudo в целом ...

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .