Это не функция в less
, но это - полезная функция.
Я люблю страницы справочника и предпочитаю меньше (1) как мой пейджер. Однако большая часть программного обеспечения GNU сохраняет руководство в информации (1) (GNU Texinfo) формат, и я не поклонник информации (1) интерфейс. Просто дайте мне меньше.
Так, я считал информацию (1) использование страниц less
вместо этого. Следующая команда распечатает информацию (1) страницы, с помощью знакомого интерфейса меньше!
info gpg |less
Имена пользователей на Unix не являются значительными. Только числовые идентификаторы пользователей. Числовой идентификатор корня всегда 0. Это трудно кодируется повсеместно (в ядре, в утилитах, и т.д.).
Можно найти числовой идентификатор пользователя путем выполнения id
.
Обратите внимание, что Ваш числовой идентификатор пользователя является свойством рабочего процесса. Когда Вы входите в систему, процесс, Вы входите в систему через (login
, sshd
, и т.д.), работает как корень (UID 0), и после того как Ваш вход в систему авторизовывается, он переключается на Ваш идентификатор пользователя и выполняет Вашу оболочку (указанный в/etc/passwd). Оттуда, для использования sudo
, su
, или что-то еще для переключения идентификаторов пользователей те программы имеют setuid набор битов (chmod u+s
или chmod 4xxx
установит это), так, чтобы, когда они выполнятся, выполнения процесса как владелец программы (корень, UID 0). Снова, после того как Вы авторизовываетесь, они запускают любую программу (независимо от того, что Вы сказали sudo
работать, оболочка, и т.д.) как корень. (В su
случай при определении другого пользователя для переключения на, это спадает до того UID, затем выполняет оболочку или что бы то ни было.)
Для ответа на другой вопрос нет действительно никакого пути к корневой учетной записи, которая "будет повреждена", так как это действительно - просто число, но могли бы быть причины, почему Вы не можете только войти в систему как корень (как упущение пароля, например). Ни один из них не должен требовать переустанавливания ОС, но они могли бы потребовать, чтобы немного технического навыка зафиксировало. (Например, если Вы забываете пароль root, можно использовать sudo для получения для укоренения при помощи пароля, начальной загрузки в однопользовательский режим для изменения пароля или начальной загрузки от живых медиа или спасательной среды.)
За 25 лет контакта с Unix я никогда не видел случай, где корневая учетная запись была повреждена без самой системы, являющейся применимым. Забытые пароли могут легко быть сброшены, и я не рассматриваю что как повреждение. Был один незабываемый инцидент на Vax, выполняющем BSD, куда я случайно (не спрашивают) удалил все из/dev, включая записи для ленточного накопителя (1/4-дюймовые ленты барабана). Это делает его немного трудно для восстановления от резервного копирования.
Под Unix действительно существует ничего для повреждения. Процесс входа в систему просто запускает оболочку и петляет из корневого каталога корня. За исключением емкостно-резистивных файлов, если остальное не работает на корень, он, вероятно, не будет работать ни на кого больше. Если Вы входите в систему как корень графической системы (KDE или Gnome), все, что я могу сказать, "Просто не делают".
У Вас может быть несколько учетных записей, что у всех есть uid 0. Это может использоваться в качестве альтернативы sudo, когда существует несколько администраторов для машины. Оборотная сторона - то, что у Вас теперь есть несколько корневых учетных записей для защиты. Вы также не получаете вход, который sudo делает для Вас.
Ответ Steven Pritchard хорош, но я думал, что предложу другую презентацию подобной информации.
Каждый процесс работает как определенный пользователь ¹. Пользователь идентифицируется числом, идентификатором пользователя, который хранится в информации о процессе, доступной только ядру. Пользователь, идентификатор пользователя которого 0, имеет специальные полномочия и обычно звонится root
; имя root
не является особенным для ядра (но если Вы измените его, то Вы, вероятно, перепутаете много приложений). Много вещей, таких как загружающиеся модули ядра, получая доступ к большинству устройств непосредственно, и так далее, требуют, что процесс, который выполняет действие работать как идентификатор пользователя 0 ².
Когда начальные загрузки системы, первый процесс, запущенный ядром, работают как суперпользователь. Тот процесс, названный init
, в конечном счете запускает много системных служб (cron
, syslogd
, …) и программы входа в систему (login
, sshd
, и т.д.).
Когда Вы входите в систему, Вы вводите учетные данные (имя, пароль, …), и программа входа в систему проверяет их. Если учетные данные приняты, изменения программы входа в систему в Вашем идентификаторе пользователя (это - одно из полномочий, предоставленных суперпользователю).
При завинчивании пользовательской базы данных (который маловероятен, если Вы не обходите редактирование или удаление случайных файлов как корень), Вы не можете входить в систему больше. Вы все еще сможете загрузиться в однопользовательский режим или с живого CD для восстановления системы.
Программа sudo
позволяет Вам команды выполнения как корень. Обычно, если Вы запускаете программу, она наследовала идентификатор пользователя процесса, который запустил ее. Но sudo
корень setuid: это - исключение, определенное битами полномочий на /usr/bin/sudo
, это заставляет его работать как идентификатор пользователя 0 вместо этого. sudo
проверки, позволяется ли пользователь, который вызвал, выполнить команду с поднятыми полномочиями (путем консалтинга /etc/sudoers
), и или выполнения команда или сигналы ошибка.
¹ Иногда больше чем один, но это не подойдет в этом ответе.
² Или имеют правильную возможность, но не берут в голову это на данный момент.
Таким образом, предыдущие ответы от Steven Pritchard и KeithB корректны, но существует несколько тонкости для знания о том, как идентификатором процесса на самом деле управляют.
Как упомянуто, имя пользователя полностью не важно ядру или любому управлению процессами, и только отображается в пространстве пользователя на основе/etc/passwd или подобных механизмов, поэтому забудьте все об этом. Корень действительно hardcoded и является uid 0 по определению в любой системе POSIX (или что-либо даже удаленно UNIXy, насколько я знаю).
Полномочия вычисляются сделанные на основе свойств в настоящее время процесса выполнения. Существует реальный uid, который является uid пользователя, который запустил процесс и эффективный uid, который является uid, процесс рассматривают что касается целей полномочий. При выполнении вещей от оболочки оболочка является родительским процессом - и дочерние процессы всегда наследовали реальный uid родителя, который является uid, если Вы работаете в оболочке входа в систему. Процессы, для которых включен setuid, могут изменить свой эффективный uid (но никогда свой реальный или сохраненный uid) - процессы, работающие с эффективным uid 0 (как корень), могут измениться на любой другой uid, и другие процессы могут только изменить euid между реальным и сохраненным uid - другое свойство процесса, которое всегда является исходным euid процесса (эквивалентно, эффективный uid родителя в точке, когда exec()
был назван). Это не может быть изменено непривилегированными пользователями, и корень может изменить его только на реальный uid.
Все те также важны для полномочий группы, просто s/uid/gid.
Как в стороне, я обычно нахожу sudo менее полезный, чем включение su и правильно управление группой колеса.
Концепция привилегии «root» распространяется на различные механизмы управления:
https://en.wikipedia.org/wiki/Protection_ring
И одной из привилегированных инструкций является управление таблицей страниц памяти. И эти различные кольца также дают вам потоки выполнения пространства между ядром и пользователем -.
https://en.wikipedia.org/wiki/Kernel_page-table_isolation
https://manybutfinite.com/post/cpu-rings-privilege-and-protection/
Кольцо 0 будет иметь больше привилегий и хранить всю вашу конфиденциальную информацию, -в том числе информацию о вашем USERID. Если у вас userid=0, вы привилегированный, а если нет, то просто обычный пользователь. И у каждого идентификатора пользователя есть разные таблицы страниц в ядре -, поэтому каждый процесс не может напрямую изменять память друг друга. И помните, что идентификатор пользователя хранится в памяти кольца 0 -ваши процессы, работающие в кольце 3, никогда не смогут изменить эту информацию, и если вы можете, то вам, должно быть, удалось перейти в ядро, чтобы изменить ее ("привилегия эскалация» ).
Чтобы проверить, являетесь ли вы пользователем root или нет -root -, сделайте это в ядре:
if (current_cred()->uid != 0)
return -EPERM;
А если вы не в ядре -, у вас нет доступа ко всем учетным данным, хранящимся в ядре. И один процесс не может прочитать память другого процесса -, поэтому такая проверка не нужна, если вы не находитесь в ядре, которое может видеть ВСЮ память для всех процессов.
Подводя итог :любые запущенные вами процессы, которые всегда выполняются с привилегией кольца 3 (для Intel ),будет иметь информацию об идентификаторе пользователя, хранящуюся в ядре -, которое должно быть изначально создано из другого компонента ядра или корневого процесса (userid = 0 ). Любой процесс, принадлежащий root -, (, который все еще работает в кольце3 ), будет иметь возможности (, почему? потому что он написан внутри самого исходного кода ядра Linux:
https://stackoverflow.com/questions/15774548/check-for-user-root-within-linux-kernel)для легкого перехода в привилегию кольца 0 . Это объясняет, почему независимо от того, как вы изменяете свою собственную память, (которая работает в кольце 3 ), вы никогда не сможете увидеть/изменить свой идентификатор пользователя.
И вы спросили, хранится ли право собственности в файлах -да, файлы действительно содержат идентификатор пользователя. И запущенный процесс (с определенным идентификатором пользователя )не может изменять другие файлы с другим идентификатором пользователя. Таким образом, безопасность разделяется на файлы + запущенные процессы (, где идентификатор пользователя хранится в памяти ядра ). Но вы не можете быть полностью уверены, что кто-то другой не сможет прочитать ваши физические файлы.
Если вы можете перенести жесткий диск на другую машину , на которой у вас есть root-права, вы можете предположить, что ЛЮБОЙ идентификатор пользователя необходим для чтения физических файлов, принадлежащих этому конкретному пользователю -на жестком диске. т.е., если у вас нет физической защиты, вы можете обойти все механизмы защиты на жестком диске, если только он не зашифрован.