Как работает обнаружение sudo / root-ness

Программы, которые вносят изменения в систему, требуют sudo если я уже не являюсь пользователем root .

Теперь возникает вопрос: как именно система выясняет, что я (а не) корень?

Имеет ли это:

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

  • Проверить на известный идентификатор самого корня (т.е. «корень пользователя» жестко закодирован в исходный код)?
    Если да, то что произойдет, если моя корневая учетная запись будет повреждена? Будет ли я вынужден переустановить ОС, так как нет возможности создать еще одну учетную запись с правами root?

  • Проверьте мое имя / группу на содержимое какого-либо файла и предоставите правильную привилегию? Если да, то какой файл содержит эту информацию?

  • Сделайте что-нибудь еще? Если да, то что он делает?

  • Как скрипт может выполнять привилегированные команды на удаленной системе без паролей sudo или ssh?
  • Получение отказа в доступе при попытке добавить текст в файл с помощью sudo
  • Можем ли мы установить пакет через сценарий оболочки?
  • форсирование sudo на удаленном сервере rsync
  • su или sudo - как узнать, какой из них будет работать?
  • Как вы автоматически повышаете автоматическую задачу до привилегий root или существует альтернативный подход?
  • Как я могу заставить sudo отказаться от всех переменных среды?
  • Предпочитаете sudo over su, используя отдельного пользователя с полными привилегиями sudo?
  • 4 Solutions collect form web for “Как работает обнаружение sudo / root-ness”

    Имена пользователей в Unix не значимы. Только числовые идентификаторы пользователя. Числовой идентификатор корня всегда равен 0. Это жестко закодировано повсюду (в ядре, в утилитах и ​​т. Д.).

    Вы можете найти свой цифровой идентификатор пользователя, запустив id .

    Обратите внимание, что ваш числовой идентификатор пользователя является свойством выполняемого процесса. Когда вы входите в систему, процесс входа в систему ( login , sshd и т. Д.) Выполняется под управлением root (UID 0), и после авторизации вашего входа он переключается на ваш идентификатор пользователя и запускает вашу оболочку (указанную в / etc / passwd ). Оттуда, чтобы использовать sudo , su или что-то еще для переключения идентификаторов пользователей, эти программы имеют установленный бит setuid ( chmod u+s или chmod 4xxx установит это), так что, когда они выполняются, процесс выполняется как владелец программа (root, UID 0). Опять же, как только вы авторизованы, они запускают любую программу (независимо от того, что вы сказали sudo для запуска, оболочки и т. Д.) Как root. (В случае su , если вы укажете другого пользователя для переключения, он падает до этого UID, затем запускает оболочку или что-то еще.)

    Чтобы ответить на ваш другой вопрос, у корневой учетной записи «коррумпированный» нет никакого способа, потому что это действительно просто число, но могут быть причины, по которым вы не можете просто войти в систему как root (например, забыть пароль) , Ни один из них не требует переустановки ОС, но для их исправления может потребоваться некоторое техническое мастерство. (Например, если вы забыли пароль root, вы можете использовать sudo для доступа к root, используя свой пароль, загрузитесь в однопользовательский режим, чтобы сбросить пароль, или загрузитесь с живого медиа или в спасательную среду.)

    За 25 лет работы с Unix я никогда не видел случая, когда корневая учетная запись была повреждена без использования самой системы. Забытые пароли можно легко сбросить, и я не вижу это как коррупцию. Был один незабываемый случай, когда Vax запускал BSD, где я случайно (не спрашиваю) удалял все из / dev, включая записи для ленточного накопителя (ленты на 1/4 дюйма). Это немного усложняет восстановление резервное копирование.

    В Unix действительно нет ничего, что могло бы испортить. Процесс входа в систему только запускает оболочку и запускает файлы rc из домашнего каталога root. За исключением файлов rc, если остальные не работают для root, это, вероятно, не сработает ни для кого другого. Если вы входите в систему с правами администратора в графическую систему (KDE или Gnome), все, что я могу сказать, это «Просто не делать».

    У вас может быть несколько учетных записей, у которых все есть uid 0. Это может быть использовано как альтернатива sudo, когда для машины есть несколько администраторов. Недостатком является то, что теперь у вас есть несколько учетных записей root. Вы также не получаете регистрацию, которую sudo делает для вас.

    Ответ Стивена Притчарда хорош, но я думал, что предлагаю другую презентацию подобной информации.

    Каждый процесс выполняется как определенный пользователь¹. Пользователь идентифицируется номером, идентификатором пользователя, который хранится в информации процесса, доступной только ядру. Пользователь с идентификатором пользователя 0 имеет специальные привилегии и обычно называется root ; root имени не является особым для ядра (но если вы его измените, вы, вероятно, запутаете много приложений). Многие вещи, такие как загрузка модулей ядра, доступ к большинству аппаратных устройств напрямую и т. Д., Требуют, чтобы процесс, выполняющий действие, выполнялся как идентификатор пользователя 0².

    Когда система загружается, первый процесс, запускаемый ядром, запускается как суперпользователь. Этот процесс, называемый init , в конечном итоге запускает ряд системных служб ( cron , syslogd , …) и программ login ( login , sshd и т. Д.).

    Когда вы входите в систему, вы вводите учетные данные (имя, пароль, …), и программа регистрации проверяет их. Если учетные данные приняты, программа входа в систему изменяется на ваш идентификатор пользователя (это одна из привилегий, предоставляемых суперпользователю).

    Если вы испортите пользовательскую базу данных (что маловероятно, если вы не будете заниматься редактированием или удалением случайных файлов с правами администратора), возможно, вы больше не сможете входить в систему. Вы по-прежнему сможете загрузиться в однопользовательский режим или с живого компакт-диска для восстановления вашей системы.

    Программа sudo позволяет запускать команды как root. Обычно, если вы запускаете программу, она наследует идентификатор пользователя процесса, который его запускал. Но sudo – это setuid root: это исключение, определяемое битами разрешения на /usr/bin/sudo , которые заставляют его запускаться как идентификатор пользователя 0. sudo проверяет, может ли пользователь, который его вызвал, запустить команду с повышенными привилегиями (путем консультаций /etc/sudoers ) и либо запускает команду, либо сигнализирует об ошибке.

    ¹ Иногда более одного, но в этом ответе не будет.
    ² Или иметь правильную возможность , но не обращайте на это внимания.

    Таким образом, предыдущие ответы Стивена Притчарда и KeithB верны, но есть несколько тонкостей, о которых нужно знать о том, как фактически управляется идентификатор процесса.

    Как уже упоминалось, имя пользователя совершенно не имеет отношения к ядру или управлению процессами и отображается только в пользовательском пространстве на основе / etc / passwd или подобных механизмов, поэтому забывайте об этом. Корень действительно жестко запрограммирован и является uid 0 по определению в любой системе POSIX (или что-то даже удаленно UNIXy, насколько мне известно).

    Разрешения рассчитываются на основе свойств текущего исполняемого процесса . Существует реальный uid , который является uid пользователя, который начал процесс, и эффективного uid , который является uid, процесс рассматривается как для целей разрешений. Когда вы запускаете вещи из оболочки, оболочка является родительским процессом, и дочерние процессы всегда наследуют реальный uid родителя, который является вашим uid, если вы работаете в оболочке входа. Процессы, для которых включен setuid, могут изменять их эффективный uid (но не их реальный или сохраненный uid). Процессы, работающие с эффективным uid 0 (как root), могут меняться на любой другой uid, а другие процессы могут изменять только euid между real и saved uid – другое свойство процесса, которое всегда является исходным euid процесса (эквивалентно, эффективный uid родителя в момент, когда был вызван exec() ). Это не может быть изменено непривилегированными пользователями, а root может изменить его только на реальный uid.

    Все это также относится к групповым разрешениям, просто s / uid / gid.

    В стороне, я обычно считаю sudo менее полезным, чем включение su и правильное управление группой колес.

    Linux и Unix - лучшая ОС в мире.