Почему я могу создавать пользователей с одинаковым UID?

Ответ здесь - то, что Linux не защищает Вас от себя.

, Если Вы действительно хотите к su root и входите в / и т.д. файлы и дают всем пользователям тот же UID, Вы можете. Это - просто текстовый файл.

, Но Вы действительно не были должны и это иметь непреднамеренные последствия.

Существуют на самом деле допустимые причины этого. Например, я раньше работал в лаборатории, где у каждого из нас был наш собственный компьютер, но наш $HOME был в общем диске, экспортируемом сервером. Так, мой $HOME был

/users/terdon

Начиная с /users, папка была на самом деле не на моей локальной машине, но экспортировала по NFS для любого анализа, который был тяжел на вводе-выводе, я буду использовать данные, хранившие на моих локальных жестких дисках, чтобы не обременить сеть лаборатории. С этой целью у меня и всех других, было два пользователя: тот, который был в масштабе всей системы и тот, который был локален для рассматриваемой машины. Дом локального пользователя был

/home/localuser

Однако, у меня должен был быть полный доступ к моим файлам, был ли я зарегистрирован как terdon или как localuser и способ, которым наш системный администратор реализовал, который был путем предоставления и localuser и terdon тот же UID. Тем путем я мог свободно управлять своими локальными файлами, независимо от которого пользователя я был в настоящее время зарегистрирован как.

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

На самом деле довольно распространено иметь двух пользователей с тем же идентификатором. На FreeBSD обычно существует два пользователя с UID 0: корень и toor. Корень использует встроенную оболочку/bin/sh, и toor использует различную оболочку, обычно колотите.

Системы 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:, числа - то, что на самом деле записано в диск!

В Linux все пользователи и группы являются на самом деле просто числами. Это что вывод id управляйте, чтобы Вы отправили шоу.

/etc/passwd имена пользователей карт файлов к идентификаторам пользователей (числа) и в примере, который Вы имеете, обеспечивают, Вы просто отобразили два имен пользователей на тот же идентификатор пользователя.

Эффективно, Вы создали одного пользователя, test12, Идентификатор 1005, у кого также есть второе имя пользователя test13. Однако система отобразит UID 1005 на первое имя пользователя, которое это находит, который был бы test12

Linux "позволяет" Вам сделать это, потому что нет никакой системы, чтобы препятствовать тому, чтобы Вы делали это. /etc/passwd просто текстовый файл, имена пользователей отображаются на UID, найденном для их записи в том файле, UIDs отображаются на первом имени пользователя, найденном в том файле.

Но то, что Вы создали, является запутывающей ситуацией для других системных администраторов; избегайте его путем изменения UID test13

причина, что это позволяется сегодня, состоит просто в том, потому что система не предотвращает его.

, Если бы это изменилось, то это повредило бы те системы, где у администраторов было использование для этой функции, (см. пример 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 в сценарии, который сначала выбирает следующий уникальный идентификатор из базы данных (файл) для установки уникального идентификатора, если это - то, что Вы хотите. Это - открытый исходный код, в конце концов.

/etc/passwd файл просто отображает символьные имена пользователей на реальный идентификатор пользователя. Если Вы сознательно сделаете два символьных имени, которые отображаются на один идентификатор пользователя тогда, то он позволит Вам.

, Который не означает, это - хорошая идея на самом деле сделать это. Некоторые люди, возможно, нашли очень определенные случаи использования, где они могут использовать в своих интересах эту функцию, но в целом Вы не должны делать этого.

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

Существуют идентификаторы, что операционная система ожидает быть уникальной, но они используются для отслеживания аппаратных средств. Знание, что деталь Универсально Уникальный идентификатор соответствует жесткому диску, содержащему системные файлы, может помочь ему продолжить работать если изменения настроек оборудования. Microsoft называет эти Глобально уникальные идентификаторы и использует их для отслеживания всего программного обеспечения Windows. Как ни странно, эти акронимы были плохо выбраны.

С точки зрения ОС, большая часть пользователя и изменений идентификатора группы означают изменение его внешнего интерфейса. Это могло обычно функционировать несмотря на коллизии; главным образом, что требуется пользователей системы, и группы то, что они существуют. Это не может знать то, чего требуют пользователи. В таких ситуациях философия Unix - то, что ОС должна предположить, что администраторы знают то, что они делают и должны помочь им сделать это быстро.

Я нашел некоторое доказательство, которое поддерживает ответ @andybalholm.

От APUE, В§8.15:

Любой процесс может узнать свой реальный и эффективный идентификатор пользователя и идентификатор группы. Иногда, однако, мы хотим узнать имя для входа в систему пользователя who’s запущение программы. Мы могли звонить getpwuid (getuid ()), но что, если у отдельного пользователя есть несколько имен для входа в систему, каждый с тем же идентификатором пользователя? ( у человека А могли бы быть многократные въезды в файле паролей с тем же идентификатором пользователя, чтобы иметь другую оболочку входа в систему для каждой записи .) Система обычно отслеживает имя, мы входим в систему под (Раздел 6.8), и эти getlogin, функция позволяет выбирать то имя для входа в систему.

....

, Учитывая имя для входа в систему, мы можем затем использовать его для поиска пользователя в файле паролей — для определения оболочки входа в систему для example— использование getpwnam.

Btw, я хотел бы знать, можно ли переключиться на другую оболочку, в то время как зарегистрированный.