Когда были созданы эти пользователи?
В тех случаях, которые вы упомянули, они были созданы при установке системы. Эти учетные записи являются обычными, некоторые датируются десятилетиями. Они также стандартизированы. Стандартная база Linux делит их на:
- требуется стандартные пользовательские учетные записи,
root
, bin
, и daemon
; и
- необязательно стандартные пользовательские учетные записи
adm
, lp
, sync
, shutdown
, halt
, mail
, news
, uucp
, operator
, man
, иnobody
Другие учетные записи пользователей, которые упоминаются здесь - pulse
, avahi
, colord
, и Debian-exim
(выбрать один из файла паролей py4on в) - привести нас к следующему вопросу.
Как они связаны с установкой новых программ?
Нестандартные учетные записи пользователей создаются и уничтожаются «сценариями сопровождающего» для различных пакетов по мере их установки и очистки. Учетная запись пользователя будет создана с помощью так называемого postinst
сценария сопровождающего пакета , который запускается, getent
чтобы увидеть, существует ли учетная запись пользователя, и useradd
если нет. Теоретически он будет удален postrm
запущенным так называемым сопровождающим скриптом пакета userdel
.
На практике учетные записи пользователей для пакетов не удаляются. Вики Fedora (см.) Объясняет, что это будет сопряжено с трудностями. См. Ошибку Debian # 646175 для примера такого обоснования в действии, где принято решение просто не удалять rabbitmq
учетную запись пользователя при очистке пакета, чтобы решить проблему с демоном, который продолжает работать под эгидой этой учетной записи.
Как эти программы запускались с разными UID?
В Unix и Linux процесс, работающий под эгидой суперпользователя, может изменить свою учетную запись пользователя на что-то другое и продолжить выполнение той же программы, но обратное не допускается. (Нужно использовать механизм set-UID.)
Система управления демоном работает как суперпользователь. Его данные конфигурации указывают, что определенные демоны работают под эгидой определенных учетных записей пользователей:
- В System 5
rc
сценарий /etc/init.d
использует вспомогательный инструмент, такой как start-stop-daemon
и его --chuid
опция.
- С менеджером службы Daemontools семьи,
run
сценарий вызывает setuidgid
, s6-setuidgid
, chpst
или runuid
с именем учетной записи пользователя. В /unix//a/179798/5132 есть примеры этого, которые устанавливают nagios
учетную запись пользователя.
- С upstart
setuid
в файле задания есть строфа, в которой указана учетная запись пользователя. Это не очень мелкозернистое, и иногда хочется того, что описано на /superuser//a/723333/38062 .
- При использовании systemd
User=
в файле сервисной единицы есть настройка, определяющая учетную запись пользователя.
Когда система управления демоном порождает процесс, чтобы стать демоном, эти механизмы отбрасывают привилегии суперпользователя, так что процесс демона продолжает выполняться под эгидой непривилегированной учетной записи пользователя.
Есть довольно длинное объяснение, почему хорошее управление демонами осуществляется именно так. Но ты не спросил почему; только когда, как и откуда. ☺ Поэтому очень краткое описание:
Операционные системы Unix и Linux изолируют процессы, выполняемые под эгидой разных учетных записей друг от друга. Исторически сложилось так, что если кто-то мог захватить демона, который был суперпользователем, он мог делать все, что ему нравилось. С другой стороны, демон, работающий под эгидой непривилегированной учетной записи, может получать доступ только к файлам, каталогам, устройствам и процессам, доступным для этой непривилегированной учетной записи. Систему взаимных недоверчивых программ-демонов, работающих под эгидой разных учетных записей пользователей и неспособных получить доступ / контролировать внутренние (доверенные) файлы / каталоги / процессы / устройства друг друга, следовательно, взломать намного сложнее.
дальнейшее чтение