Як ОС знає, що команді потрібен sudo?


16
  1. Коли ви запускаєте виконуваний файл, іноді ОС відмовить вашому дозволу на. Наприклад, біг make installз префіксом, який є системним шляхом, знадобиться sudo, тоді як префікс несистемний шлях не буде запитуватися sudo. Як ОС вирішує, що для запуску виконуваного файлу потрібно більше привілеїв, ніж у користувача, ще до того, як програма щось зробить?
  2. Іноді на запуск програми не буде відмовлено у дозволі, але програма зможе зробити більше речей, якщо вона запускається sudo. Наприклад, при запуску duв деякому системному каталозі лише з sudoним буде доступ до деякого каталогу. Чому ОС не відмовляє в дозволі на запуск такої програми, або дружнє повідомлення надає більше привілеїв, перш ніж програма може запуститися?
  3. Чи правда, що коли sudoпрацює, suтеж буде працювати, і коли suпрацює, sudoтакож буде працювати? або з su, користувач може зробити більше, ніж з sudo? Як ОС вирішує, коли sudoпрацює і коли suце потрібно?

Ви відповіли на це запитання чи хочете отримати більше інформації?
ctrl-alt-delor

Відповіді:


14
  1. Іноді повідомлення "Відмовлено у дозволі" пов’язане з дозволами файлової системи, наприклад, забороняючи доступ до запису. Виконавчий файл / інструмент просто перевіряє, чи надає файлова система достатньо дозволів для того, щоб робити те, що ви збираєтесь робити, і видає помилку, якщо файлова система її відхиляє. В іншому випадку інструмент сам перевірить ваш ідентифікатор користувача, перш ніж дозволить продовжувати його використовувати.
  2. Коли ви запускаєте програму, sudoви запускаєте її під іменем іншого користувача. Якщо цей користувач "здатний робити більше справ", ніж ваш користувач, а sudoконфігурація дозволяє робити ці дії від імені іншого користувача, то так, sudoце дозволить вам робити більше справ. Однак це не обов'язково. Якщо ви просто застосуєте sudoна початку командного рядка, ви насправді є sudoяк root, тому зазвичай ви можете зробити більше речей, ніж просто смертний.
  3. Більшість точно не. Для використання sudoвам потрібно ввести власний пароль користувача, і тоді вам дозволяється робити деякі дії від імені цільового користувача. Для використання suвам потрібен пароль цільового користувача, і якщо він у вас є, ви стаєте цим цільовим користувачем, що стосується системи, і ви можете робити все, що може зробити користувач.

Дивись також


Спасибі. Чи "дозволи дозволу на файлову систему відмовляють у доступі до запису" = "У режимі доступу до файлу не встановлено біт виконання для користувача, який може бути встановлений chmod"?
StackExchange для всіх

1
@ Тім На насправді = «режим доступу файлу не має запис набору біт для користувача». І так, це, звичайно, можна виправити за chmodумови, що ви або власник файлу, або root.
Джозеф Р.

Чи потрібно судо, повністю і виключно залежать від того, чи не встановлений біт виконання для користувача? Дивіться unix.stackexchange.com/q/147052/674
StackExchange для всіх

@Tim Очевидно, що вам потрібен біт виконання, щоб мати можливість запустити виконуваний файл в першу чергу.
Джозеф Р.

1
@JosephR. Не очевидно. chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./helloстворює приємне "Привіт, світ!" вихід.
doneal24

24

Для описаних вами цілей ОС не вирішує, чи потрібно вам судо для початкового запуску програми. Натомість після запуску програми, а потім намагається зробити щось, що не дозволяється поточним користувачем (наприклад, записати файл /usr/binдля встановлення нової команди), ОС забороняє доступ до файлу. Дія, яку слід вжити за цією умовою, залежить від програми; makeперестає працювати, але duпісля друку повідомлення перейде до наступного файлу / каталогу.

Команди suі sudoє двома різними способами запуску програми з правами root. Вони можуть відрізнятися незначними деталями, такими як вміст середовища при запуску нової програми, залежно від використовуваних параметрів. ОС не потрібно вирішувати, коли може працювати одна чи інша.


6

suі sudoє пільговими програмами. suзмінює (після успішної автентифікації) реального та ефективного ідентифікатора користувача та групи на ідентифікатор користувача, якому ви suє. Таким чином, suподібний до login. Зауважте, що suїх можна використовувати для зміни будь-якого користувача, а не лише для root. sudoтакож змінює дійсні та ефективні ідентифікатори користувачів та груп. До цього моменту suі sudoсхожі (але не пов'язані), крім того , вони дуже різні.

З цим suвам потрібно знати пароль цілі, і коли ви зареєструвались, ви можете робити все, що завгодно, як цей користувач. Використання suможна обмежити, встановивши SU_WHEEL_ONLYв /etc/login.defs. Якщо це встановлено, користуватися wheelможуть лише користувачі групи su, інакше це не обмежено. Крім того, suє все або нічого.

sudoзовсім інше щодо цього. З sudoвами можна визначити досить складні політики в /etc/sudoersна те , що sudoer (користувач , який дзвонить sudo) дозволено робити. Наприклад, ви можете визначити політику, де певні користувачі можуть запускати лише певні програми з певними привілеями, тоді як інші користувачі можуть запускати інші програми з іншими привілеями.

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


2

tl; dr Доступ визначається користувачем, який запускає додаток, і sudoзапускає програми як інший користувач.

Повна версія:

Як ОС знає, що команді потрібен sudo?

Це не знає. UNIX керує дозволами не на рівні програми, а на рівні файлової системи: користувачам надаються дозволи на доступ до певних файлів. Потім програми запускаються від імені користувача - кожен запущений процес має з ним асоційованого користувача. Цей користувач використовується для визначення дозволів для цієї програми. Судо працює, запускаючи програми від імені іншого користувача (з дозволами, пов’язаними з цим іншим користувачем), а саме rootсуперпользователя.

Що стосується ваших прикладів:

  1. Якщо користувач має доступ до запису до певного каталогу, він може make installпотрапити до цього каталогу. Інакше вони можуть це rootзробити - використовуючи sudo.

  2. Якщо ви не можете отримати доступ до файлів у каталозі, duдля запуску ви також не можете отримати доступ до них. rootможе отримати доступ практично до кожного файлу, тому sudo du( duзапустити від імені root) може також отримати доступ до них.

Це правда, що коли судо працює, су також буде працювати, і коли су працює, судо також буде працювати?

Так і ні. Так, якщо програма насправді запускається, вона повинна поводитись однаково під обома sudoі su. Однак sudoпередбачає можливість більш тонкого контролю того, хто може запускати те, що визначається набором правил, що зберігаються у /etc/sudoersфайлі. suпростіше - якщо ви знаєте пароль цільового користувача, ви можете запускати програми від імені цього користувача.

Останнє зауваження: те, як програма обробляє відмову в доступі (якщо вона скасовує або ігнорує або попереджає користувача), залежить від застосування.


1

Ніхто ще не має ✓, тому я зібрав відповідь, у якій є все, що я міг придумати.

1 Під час запуску виконуваного файлу іноді ОС відмовить вашому дозволу на. Наприклад, для запуску make install з префіксом, який є системним шляхом, знадобиться sudo, тоді як префікс як несистемний шлях не буде запитуватися для sudo. Як ОС вирішує, що для запуску виконуваного файлу потрібно більше привілеїв, ніж у користувача, ще до того, як програма щось зробить?

Ні, це не робиться при запуску виконуваного файлу. Це робиться, коли виконуваний файл намагається щось зробити.

Os перевірять дозволи та можливості файлової системи (вони не охоплені дозволами файлової системи, і включають зменшення приємного рівня, mknode, деяких мережевих матеріалів низького рівня, вбивають процеси інших, перезавантажують, встановлюють час тощо). Якщо у вас немає дозволів, ви не можете цього зробити. Root має повний набір можливостей, включаючи CAP_DAC_OVERRIDE (ігнорування дозволу на файл).

2 Іноді на запуск програми не буде відмовлено у дозволі, але програма зможе зробити більше речей, якщо вона запускається з sudo. Наприклад, при запуску du в деякому системному каталозі, лише за допомогою sudo він зможе отримати доступ до деякого каталогу. Чому ОС не відмовляє в дозволі на запуск такої програми, або дружнє повідомлення надає більше привілеїв, перш ніж програма може запуститися?

ОС не може знати, що буде робити програма. Тому програма повинна перевірити дозволи перед її запуском та вирішити, що робити. Але цього не потрібно робити.

Примітка: на android є маніфест, в цьому додаток оголошує, якими привілеями він може користуватися. ОС знищить будь-яку програму, яка намагається використовувати привілей, який він не декларує, а ОС не завжди гарантує, що привілей може бути шанований. наприклад, доступ до мережі може бути недоступний.

2 Чи правда, що коли судо працює, су також буде працювати, і коли су працює, судо також буде працювати? або із су, користувач може зробити більше, ніж із судо? Як ОС вирішує, коли працює sudo і коли su потрібен?

sudoі suзробіть приблизно щось. Деякі відмінності полягають у змінній обробці середовища та інших подібних проблемах уникнення безпеки. Однак вони обидва інструменти, що дозволяють вам стати іншим користувачем, і обидва мають користувача root за замовчуванням.

su був оригінальним інструментом, він вимагає ввести пароль користувача / групи, до якого ви змінюєтеся.

sudoновітня і вимагає, за замовчуванням, введення власного пароля, але може бути налаштована на прийняття пароля користувача / групи, на який ви переходите, або взагалі немає пароля. Він також дозволяє безліч конфігурацій, з якими командами він буде працювати, для кого і як він буде автентифікувати цю програму для цього користувача на цій машині. Також sudoeditце є частиною sudoі може бути використане для дозволу редагування як іншого користувача та уникнення проблеми безпеки підсумкового обстрілу з редактора (виклик exec з редактора для запуску довільного процесу з нарощеними привілеями).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.