Як sudo вирішує, запитувати пароль, коли йому дана команда, яка насправді не потребує `sudo`?


10

Застосовуючи sudoдо команди, яка насправді не потрібна sudo,

  • іноді він не запитує мене паролем. Наприклад під моїм $HOME, sudo ls.

  • Але я пам’ятаю, що це робить для якоїсь іншої команди, хоча я забуваю, яку саме.

Тож мені було цікаво, як sudoвирішується запитувати пароль, коли йому дана команда, яка насправді не потрібна sudo? Чи є якесь правило, щоб /etc/sudoersвказати це?

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


15
Рішення про те , програма буде намагатися зробити що - то , що тільки корінь може зробити, або отримати доступ до файлу , що викликає користувач заборонений доступ, без запуску програми, є проблема зупинки в маскуванні. Тож ви можете бути впевнені, що це не судо.
zwol

2
+1, оскільки, хоча питання ґрунтується на помилковому уявленні, симптоми чітко пояснюються, і на нього є одна однозначна відповідь.
декор

Відповіді:


22

У типовій конфігурації команда не має значення. Вам потрібно ввести свій пароль під час першого використання sudo, і вам не знадобиться ваш пароль у цій конкретній оболонці протягом наступних 15 хвилин.

З точки зору комп'ютера, немає такої речі, як "команда, якій потрібен sudo". Будь-який користувач може спробувати запустити будь-яку команду. Результат може бути не що інше, як повідомлення про помилку, наприклад "Дозволено відмовлено" або "Немає такого файлу чи каталогу", але команду завжди можна запустити.

Наприклад, якщо ви працюєте duна дереві каталогів, який містить вміст, на який ви не маєте дозволу на доступ, ви отримаєте помилки дозволу. Ось що означає "відмова у дозволі". Якщо ви запускаєте sudo du, sudo запускається duяк root, тому ви не отримуєте помилок дозволу (у цьому і полягає кореневий обліковий запис: root¹ завжди має дозвіл). Коли ви запускаєте sudo du, він duпрацює як root і sudoзовсім не бере участь після duзапуску. Чи зустрічається du з помилками дозволу, абсолютно не має значення для того, як працює sudo.

Є команди, яким потрібно судо, щоб зробити щось корисне . Корисність - поняття людини. Вам потрібно використовувати sudo (або деякі інші методи для запуску команди як root), якщо команда робить щось корисне, коли запускається як root, але не тоді, коли запускається під вашим обліковим записом.

Від того, чи буде Судо запитувати ваш пароль, залежить від двох речей.

  1. Виходячи з конфігурації, sudo вирішує, чи потрібно вам пройти автентифікацію. За замовчуванням sudo вимагає пароль. Це можна вимкнути кількома способами, включаючи встановлення authenticateпараметра false та встановлення відповідного правила з NOPASSWDтегом.
  2. Якщо sudo вимагає ваш пароль, може бути вміст використовувати кешоване значення. Це нормально, тому що причина sudo потребує вашого пароля - це не автентифікація того, хто його викликає (sudo знає, який користувач викликав його), а підтвердження того, що це все-таки ви в командах, а не хтось, хто взяв під контроль вашу клавіатуру. За замовчуванням sudo готовий вірити, що ви все ще в командах, якщо ви ввели свій пароль менше 15 хвилин тому (це можна змінити за допомогою timeoutпараметра). Потрібно ввести пароль у тому ж терміналі (так що якщо ви залишаєтесь увійти на одному терміналі, тоді залиште цей термінал без нагляду, а потім використовуйте інший термінал, хтось може "tty_tickets

¹ майже, але це виходить за межі цього потоку.


Можуть бути файли, у яких виконуваний біт встановлений лише для root, а не для інших. Це може бути падіння unter "потрібно виконувати root". (Тільки нитчінг.)
Паоло Еберман

@ PaŭloEbermann Я писав: "будь-який користувач може спробувати запустити будь-яку команду", щоб уникнути викривлення цього (рідкісного) випадку. Завжди є грізник :(
Жил "SO - перестань бути злим"

45

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

Якщо ви використовуєте конфігурацію Debian за замовчуванням, найімовірніше, що тут пов’язано: останній раз sudoзапитає ваш пароль при першому використанні його в будь-якому даному терміналі, то він буде зберігати маркер автентифікації протягом певного часу. Якщо ви повторно використовуєте sudoв тому ж терміналі протягом цього терміну, він не запропонує вам ввести пароль.


Дякую. Ви маєте на увазі, sudo du /path/to/some/dirчи повинен мені завжди потрібен мій пароль, або ніколи, незалежно від /path/to/some/dir?
Тім

12
Так. Завжди знадобиться ваш пароль (чи ні). Зрозуміло, що якщо вам потрібен ваш пароль, але він вже збережений у кеші, він не запропонує вам ввести його.
dr_

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

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

6

до команди, яка насправді не потребує sudo

Справа не в тому, що команді потрібно чи не потрібно sudo. Коли ти біжиш

sudo -u user command

система виконує commandяк user.

Успішна чи ні виклик і запитання пароля чи ні, залежить від політики безпеки sudoers(зазвичай налаштована в /etc/sudoers).

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