Я понимаю, что UID - это уникальное положительное целое число, назначаемое Unix-подобной операционной системой каждому пользователю. Каждый пользователь идентифицируется в системе по его UID, а имена пользователей обычно используются только как интерфейс для людей.
Как два пользователя могут иметь одинаковый UID, не является ли это конфликтом для моей системы и пакетов?
root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#
Я добавил двух пользователей с одинаковыми UID и GID: test12
и test13
Вывод /etc/passwd
:
client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh
Я добавил пользователей useradd -ou 1005 -g1000 username.
Я запутался, какова цель этого и может ли это повлиять на разрешения, журналы пользователей и т. д. Так что теперь, если пользователь будет добавлен с uid=0
и gid=0
, будет иметь такие же привилегии, как корневая учетная запись?
Ответ здесь - то, что Linux не защищает Вас от себя.
, Если Вы действительно хотите к su root
и входите в / и т.д. файлы и дают всем пользователям тот же UID, Вы можете. Это - просто текстовый файл.
, Но Вы действительно не были должны и это иметь непреднамеренные последствия.
В Linux все пользователи и группы являются на самом деле просто числами. Это - то, что вывод эти id
команда Вы отправили шоу.
Эти /etc/passwd
пользователь карт файлов имена пользователю идентификаторы (числа) и в примере, который Вы имеете, обеспечивают, Вы просто отобразили два имен пользователей на тот же идентификатор пользователя.
Эффективно, Вы создали одного пользователя, [112 лет], идентификатор 1005, у кого также есть второе имя пользователя test13
. Однако система отобразит UID 1005 на первое имя пользователя, которое это находит, который был бы test12
, Linux "позволяет" Вам сделать это, потому что нет никакой системы, чтобы препятствовать тому, чтобы Вы делали это. /etc/passwd
просто текстовый файл, имена пользователей отображаются на UID, найденном для их записи в том файле, UIDs отображаются на первом имени пользователя, найденном в том файле.
, Но то, что Вы создали, является запутывающей ситуацией для других системных администраторов; избегайте его путем изменения UID test13
На самом деле довольно распространено иметь двух пользователей с тем же идентификатором. На FreeBSD обычно существует два пользователя с UID 0: корень и toor. Корень использует встроенную оболочку/bin/sh, и toor использует различную оболочку, обычно колотите.
/etc/passwd
файл просто отображает символьные имена пользователей на реальный идентификатор пользователя. Если Вы сознательно сделаете два символьных имени, которые отображаются на один идентификатор пользователя тогда, то он позволит Вам.
, Который не означает, это - хорошая идея на самом деле сделать это. Некоторые люди, возможно, нашли очень определенные случаи использования, где они могут использовать в своих интересах эту функцию, но в целом Вы не должны делать этого.
Linux (и другой UNIXes) берет мнение, что администратор знает то, что они делают. Если Вы говорите ему делать что-то глупое тогда, что это - Ваш собственный отказ почти таким же способом, которым, если Вы говорите Вашему автомобилю приезжать утес, Вы не можете перейти к производителям и спросить, почему автомобиль позволил Вам делать это.
причина, что это позволяется сегодня, состоит просто в том, потому что система не предотвращает его.
, Если бы это изменилось, то это повредило бы те системы, где у администраторов было использование для этой функции, (см. пример Terdon). Таким образом, это никогда не изменялось, и я не думаю, что это когда-либо будет.
Первоначально были только файлы passwd и группы, и они служили своей цели. не было никакого команда adduser, никакой addgroup, файлы были отредактированы корнем с помощью vi или редактором
было несколько причуд!
для запоминания следующего идентификатора пользователя для использования, администраторам было свойственно иметь специального пользователя как последнюю строку, которая имела имя пользователя !
(потому что !
было неверное имя пользователя), и та запись использовалась для хранения следующего идентификатора пользователя. Сырая нефть, я признаю, но Она работала! Итак, почему промах пищеварительный тракт, делающий его более сложный, сродни гибкой разработке сегодня.
Там были известны дефекты. Основное существо, что это должен был быть читаемый мир, так, чтобы утилиты как ls
могли, могло отобразиться user-id => name
. Это означало, что кто-либо видел общий зашифрованный пароль и всех пользователей и идентификатор в системе.
Некоторые системы Unix начали представлять несколько сценариев оболочки adduser
addgroup
, часто они были проигнорированы, потому что они были непоследовательным между Unixes, так большинство людей, только что продолженных с ручным редактированием.
потребовалось довольно много лет, перед shadow
, файл паролей был изобретен, это обеспечило немного больше безопасности путем сокрытия зашифрованных паролей. Снова, как раз достаточно сложности было добавлено, но это было все еще довольно сыро и просто. Утилиты useradd
и groupadd
были представлены, который сохранил shadow
и shadow-
обновленным. Прежде всего, они часто были простыми обертками сценария оболочки вокруг поставщиков, собственных adduser/addgroup утилиты. Снова было как раз продолжать идти.
Сети компьютеров росли, люди работали над несколькими за один раз, чтобы сделать задания, таким образом, администратор эти passwd/group
файлы становились кошмаром, особенно с NFS, таким образом, в прибывает Желтые страницы, которые, как также известно как НИС, облегчили нагрузку.
становилось очевидно к настоящему времени, что что-то немного более гибкое было необходимо, и PAM был, был изобретен. Таким образом, если бы Вы были действительно сложны и хотели централизованный, безопасное, уникальное-id'ed, вся система аутентификации дополнительных свойств, то Вы обратились бы к центральному серверу для аутентификации, возможно, сервер Радиуса, сервер LDAP или каталог Active.
мир вырос. Но passwd/group/shadow файлы все еще остались для нас меньшими пользователями/разработчиками/лабораториями. Мы все еще действительно не потребовали всех дополнительных свойств. Я предполагаю, что философия изменилась немного к настоящему времени на, , "Если бы Вы собирались сделать ее лучше, Вы не использовали бы ее в весь" , не волнуйтесь об этом.
Поэтому я не думаю, что простой passwd файл будет когда-либо изменяться. Больше нет никакого смысла, и это является просто большим для тех ВЈ30 Raspberry Pi с 2, возможно, контрольная температура 3 пользователей и подача Твиттера. Хорошо, просто необходимо быть немного осторожными с идентификатором пользователя, если Вы хотите их уникальный, и нет ничего, чтобы препятствовать тому, чтобы энтузиаст перенесся useradd в сценарии, который сначала выбирает следующий уникальный идентификатор из базы данных (файл) для установки уникального идентификатора, если это - то, что Вы хотите. Это - открытый исходный код, в конце концов.
Существуют идентификаторы, что операционная система ожидает быть уникальной, но они используются для отслеживания аппаратных средств. Знание, что деталь Универсально Уникальный идентификатор соответствует жесткому диску, содержащему системные файлы, может помочь ему продолжить работать если изменения настроек оборудования. Microsoft называет эти Глобально уникальные идентификаторы и использует их для отслеживания всего программного обеспечения Windows. Как ни странно, эти акронимы были плохо выбраны.
С точки зрения ОС, большая часть пользователя и изменений идентификатора группы означают изменение его внешнего интерфейса. Это могло обычно функционировать несмотря на коллизии; главным образом, что требуется пользователей системы, и группы то, что они существуют. Это не может знать то, чего требуют пользователи. В таких ситуациях философия Unix - то, что ОС должна предположить, что администраторы знают то, что они делают и должны помочь им сделать это быстро.
Существуют на самом деле допустимые причины этого. Например, я раньше работал в лаборатории, где у каждого из нас был наш собственный компьютер, но наш $HOME
был в общем диске, экспортируемом сервером. Так, мой $HOME
был
/users/terdon
Начиная с /users
, папка была на самом деле не на моей локальной машине, но экспортировала по NFS для любого анализа, который был тяжел на вводе-выводе, я буду использовать данные, хранившие на моих локальных жестких дисках, чтобы не обременить сеть лаборатории. С этой целью у меня и всех других, было два пользователя: тот, который был в масштабе всей системы и тот, который был локален для рассматриваемой машины. Дом локального пользователя был
/home/localuser
Однако, у меня должен был быть полный доступ к моим файлам, был ли я зарегистрирован как terdon
или как localuser
и способ, которым наш системный администратор реализовал, который был путем предоставления и localuser
и terdon
тот же UID. Тем путем я мог свободно управлять своими локальными файлами, независимо от которого пользователя я был в настоящее время зарегистрирован как.
Системы Unix & Linux обычно не делает ничего для запрещения дубликатов в /etc/passwd
файл. Намерение этого файла состоит в том, чтобы связать UID с физическим именем, которое может быть дисплеем инструментами командной строки такой как ls
, когда пользователь перечисляет файлы.
$ ls -n | head -5
total 986000
drwxrwxr-x. 3 1000 1000 4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--. 1 1000 1000 760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--. 1 1000 1000 972 Oct 6 20:26 abcdefg
drwxrwxr-x. 2 1000 1000 4096 Feb 11 03:34 advanced_linux_programming
другая намеченная цель этого файла состоит в том, чтобы определить то, что окружает пользователя, доберется, когда они входят в систему.
$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash
А общий вектор атаки в системах типов Unix должен добавить строки, такие как они к системе /etc/passwd
файл:
$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash
$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash
роль /etc/passwd
файл НЕ предназначен для единственного отслеживания учетных записей пользователей. Роль отслеживания имени пользователя и пароли является ответственностью /etc/shadow
файл. Файлы такой как /etc/passwd
и /etc/group
действительно предназначены для обеспечения человекочитаемого имени, когда система перечисляет файлы от дисков.
Помнят, что Ваши файлы записаны в диск с помощью UID/GID не подлинные имена.
$ stat afile
File: ‘afile’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd02h/64770d Inode: 6560621 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ saml) Gid: ( 1000/ saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
Birth: -
Уведомление Uid:
и Gid:
, числа - то, что на самом деле записано в диск!
У двух пользователей может быть тот же UID, потому что это - просто число в текстовом файле, таким образом, можно установить его на что-либо, что Вы хотите, включая значение, которое уже используется. Как Вы видели, хотя, делая так не хорошая идея.
useradd -o
Вы распознаете это you' ре за пределами нормыadduser
. Как @psusi упомянутый, это создает два логина, указывающие на тот же идентификатор до полномочий файла и т.д. Это, вероятно, также создает проблемы, так как это не случай нормальной эксплуатации и несомненно не тестируется с большим количеством пакетов. – bkawan 14.05.2020, 22:22