Судо проти кореня; якісь фактичні відмінності?

44

Я працюю з членом служби підтримки продукту, і він наполягає на тому, що мені потрібно мати root, щоб встановити серію патчів, і що судо не буде працювати; він не дає причини, але здається дуже твердим у своїх переконаннях. Переглядаючи Superuser, я не можу визначити будь-яку можливу причину цього, і підтвердження, коли я запускаю:

sudo -l

Я отримав:

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

Отримання доступу від команди Linux / server насправді кореневим - це не суттєвий процес, як я розумію, тому я вважаю за краще встановити їх самостійно.

Чи є якась практична причина, чому б sudo поводився інакше, ніж root для встановлення програмного забезпечення на сервер?

linux sudo root

— Рейнджер
джерело

2

Я думаю, ви повинні повернути його на нього. Як показали інші, існує безліч способів отримати корінь за допомогою судо, і якщо він не може надати вам конкретних причин того, чому судо не є достатньою, то у нього немає ноги, на якій слід стояти.

— Гаррет

1

Навколишнє середовище та підкоманди приходять на думку. Я думаю, що Гастур зробив гарну роботу з оточенням, а Джейен зробив роботу з підкомандами, трубопроводами та перенаправленнями.

— 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намагається змінити домашній каталог цього користувача перед запуском оболонки. Команда виконується із середовищем, подібним до того, яке користувач отримав би під час входу . У розділі Command Environment у посібнику з судерів (5) зафіксовано, як опція -i впливає на середовище, в якому виконується команда, коли використовується політика sudoers.

— Гастур
джерело

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

— fixer1234

23

Якщо у вас є повний sudoдоступ, ви можете rootкористуватися sudo su -, тому точка безпеки є спірною.

Дійсно, існує спосіб виявити різницю між програмою, яка запускається як, rootі програмою, під яку працює sudo- за допомогою getuidvs geteuid- але це надуманий трюк. Чому б патч-система зробила це?

— sds
джерело

5

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

— Крістіан Цюпіту

2

Якщо ви працюєте з, наприклад, sudo myscriptви збережете $ PATH та змінні середовища від оболонки, в якій ви знаходитесь. Якщо ви працюєте з sudo -i myscriptвами, ви біжите так, ніби ви ввійшли як root. Дивіться відповідь з нашим _zoo дзвінків :-) _

— Hastur

1

Я думаю, що важливо зазначити, що змінні середовища не можуть бути налаштовані так само, sudoяк увійти в систему як root

— secretformula

1

@dmanexe: sudo не означає суперпользователя, це "переключення користувача робити". su і sudo можуть використовуватися для переходу на будь-яких користувачів, а не тільки на суперпользователя. Крім того, немає нічого псевдо про судо, ви дійсно отримуєте фактичний корінь, коли запускаєте судо, а не щось підробляють. Зауважте, що магія судо насправді походить від встановленого дозволу біт.

— Лежать Раян

2

sds, @CharlesDuffy: Ідея, що судо і су спричиняють geteuid()і getuid()відрізняються один від одного, є міфом. su і sudo змінюють як реальні, так і ефективні ідентифікатори користувачів на ті, які мають цільовий користувач, перш ніж запустити вказану команду або оболонку, за винятком дуже незвичної ситуації, коли ви явно налаштували їх на поведінку в іншому випадку. Ви можете перевірити це (для судо), запустивши sudo id -uта sudo id -ru(обидва покажіть 0), прочитавши sudo (8) (під командою ВИКОНАННЯ ) або написавши тестову програму .

7

Є кілька відмінностей, якщо ви отримуєте кореневу оболонку, як вказував @Hastur.

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

— Джейен
джерело

1

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

— Hastur

1

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

— Ешлі Редман бакалавр
джерело

0

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

— meredithkm
джерело