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

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

/users/terdon

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

/home/localuser

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

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

Unix systems & amp; 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 системы: [!d2 ]

$ 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:, цифры - это то, что на самом деле записано на диск!

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

В Linux все пользователи и группы на самом деле являются просто цифрами. Вот что выводил вывод команды id.

Файл /etc/passwd сопоставляет имена пользователей с идентификаторами пользователей (номерами) и в примере, который вы предоставили, вы просто сопоставили два имени пользователя к одному ID пользователя.

Фактически вы создали одного пользователя, test12, ID 1005, у которого также есть второе имя пользователя test13. Однако система отобразит UID 1005 на первое имя пользователя, которое будет найдено, что будет test12

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

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

Причина, по которой это разрешено сегодня, заключается просто в том, что система не мешает ей.

Если это изменится, тогда она сломает те системы, в которых администраторы использовали эту функцию ( см. пример Тердона). Поэтому он никогда не менялся, и я не думаю, что это когда-либо будет.

Первоначально были только файлы passwd и group, и они служили своей цели. не было никакой команды adduser, никакой addgroup, файлы были отредактированы root с помощью vi или ed.

Было несколько причуд!

Чтобы запомнить следующий идентификатор пользователя, обычно для админов было обычным пользователем в качестве последней строки, которая имела имя пользователя ! (поскольку ! было недопустимым именем пользователя), и эта запись использовалась для хранения следующего идентификатора пользователя. Грубо, признаюсь, но это сработало! Итак, почему бы не разогнать кишку, что усложнило ее, сродни быстрому развитию.

Были известные недостатки. Главное, что он должен быть читаемым в мире, так что утилиты вроде ls могли бы отображать user-id => name.

Некоторые системы Unix начали вводить несколько сценариев оболочки adduser addgroup, часто они игнорировались, потому что они были в состоянии игнорировать все зашифрованные пароли всех пользователей и идентификаторов в системе.

были несогласованными между Unix, поэтому большинство людей просто продолжалось с ручным редактированием.

Прошло немало лет, прежде чем был изобретен файл паролей shadow, это обеспечило немного большую безопасность, скрывая зашифрованные пароли. Опять же, была добавлена ​​достаточно сложная сложность, но она все еще была довольно грубой и простой. Были введены утилиты useradd и groupadd, в которых обновлены shadow и shadow-. Начнем с того, что часто это были простые оболочки оболочки оболочки, связанные с запатентованными утилитами adduser .

Сети компьютеров росли, люди работали по несколько за раз, чтобы получить работу, поэтому администратор файлов passwd/group стал кошмаром, особенно с NFS, поэтому в «Желтые страницы» также известны как NIS, чтобы облегчить бремя.

Уже стало очевидным, что нужно немного более гибкое, и PAM был изобретен. Поэтому, если вы были действительно сложны и хотели иметь централизованную, безопасную, уникальную систему идентификации всех колоколов и свистов, вы могли бы обратиться к центральному серверу для аутентификации, возможно, к серверу Radius, LDAP-серверу или Active Directory. [!d12 ]

Мир вырос. Но файлы passwd / group / shadow по-прежнему оставались для нас меньшими пользователями / разработчиками / лабораториями. Мы все еще не требовали всех колоколов и свистов. Я предполагаю, что философия изменилась к настоящему времени: «Если вы собираетесь сделать это лучше, вы не будете использовать ее вообще», так что не беспокойтесь об этом.

Вот почему я не думаю, что простой файл passwd будет когда-либо изменяться. Там больше нет смысла, и это просто отлично подходит для тех 30 фунтов малины Pi с 2, может быть, 3 пользовательской температурой мониторинга и твиттер-фидами. Хорошо, вам просто нужно быть немного осторожным с вашим идентификатором пользователя, если вы хотите, чтобы они были уникальными, и нет ничего, что помешало бы энтузиасту обернуть «Если вы собираетесь сделать это лучше, вы не будете использовать его в all " в скрипте, который сначала выбирает следующий уникальный идентификатор из базы данных (файла), чтобы установить уникальный идентификатор, если это то, что вы хотите. Это открытый источник.

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

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

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

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

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