Судо против рута; какие-то реальные различия?

44

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

sudo -l

Я получил:

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

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

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

linux sudo root

— рейнджер
источник

2

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

— Гарретт

1

Окружение и подкоманды приходят на ум. Я думаю, что Hastur хорошо поработал с окружением, а Jayen хорошо поработал с подкомандами, конвейером и перенаправлением.

— jww

2

У Гарретта есть хорошее замечание, но перед тем, как я попал в потенциальный конкурс писанья, я хотел бы спросить члена службы поддержки: пробовали ли вы оба способа, и он потерпел неудачу одним из этих способов? Возможно, он был на пути к провалу, sudoи сценарии в настоящее время написаны. Если это так, то ответ SdS' может быть наиболее полезным для Вас: sudo su -.

— jww

34

Это сильно зависит от того, как вы вызываете свою программу с помощью 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и переменные окружения. Он читает файл, связанный с $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.

— Hastur
источник

Отличный ответ. Я все еще новичок в Linux, но есть ли еще одно отличие в том, что то, что вы можете использовать, sudoможет быть ограничено разрешениями в файле sudoers и действиями, так как root не имеет этих ограничений? Последняя цитата из блока, возможно, подразумевает это, но если я правильно понимаю, это похоже на еще одно существенное отличие не только от окружающей среды (или, может быть, из-за окружающей среды?).

— fixer1234

23

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

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

— ДСН
источник

5

Кстати говоря su -, он может захотеть использовать его sudo -iтак, чтобы он имел ту же среду, что и при входе в систему напрямую.

— Кристиан Чиупиту

2

Если вы запускаете, например, sudo myscriptвы сохраните переменные $ PATH и окружения из оболочки, в которой вы находитесь. Если вы работаете с sudo -i myscriptвами, вы запускаете, как если бы вы вошли в систему как root. Смотрите ответ с нашим _zoo звонков :-) _

— Hastur

1

Я думаю, важно отметить, что переменные окружения могут быть не такими же, sudoкак при входе в систему как root

— secretformula

1

@dmanexe: sudo не означает «superuser do», это «переключение пользователя do». su и sudo могут использоваться для переключения на любых пользователей, а не только на суперпользователя. Кроме того, в sudo нет ничего псевдо, вы действительно получаете настоящий root, когда запускаете sudo, а не что-то фальшивое. Обратите внимание, что магия sudo действительно исходит от бита разрешения setuid.

— Ли Райан

2

sds, @CharlesDuffy: идея о том, что sudo и su вызывают geteuid()и getuid()отличаются друг от друга, является мифом. su и sudo изменяют как действительные, так и эффективные идентификаторы пользователей на идентификаторы целевого пользователя перед запуском указанной команды или оболочки, за исключением очень необычной ситуации, в которой вы явно настроили их поведение иначе. Вы можете проверить это (для sudo), запустив sudo id -uи sudo id -ru(оба показывают 0), прочитав sudo (8) (в разделе COMMAND EXECUTION ) или написав тестовую программу .

7

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

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

— Jayen
источник

1

Справа: практическая точка зрения часто предлагает подсказки, которые труднее обнаружить только на страницах руководства. Чтобы преодолеть подобную ситуацию, вы вынуждены больше заниматься спортом [:-)], например, написать что-то вроде sudo /bin/bash -c "./patch -p0 < /root/patch". Еще более деликатным является случай, когда вы используете перенаправление для создания файла >. При первом способе вы создадите файл, который принадлежит пользователю, только если у вас достаточно прав для записи в окончательный каталог. В последнем случае вы создадите файл, принадлежащий пользователю root ... темная сторона Unix ;-)

— Hastur

1

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

— Эшли Редман BSc
источник

0

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

— meredithkm
источник