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

Я понимаю, что 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будет иметь такие привилегии, как учетная запись root?

Ответ здесь заключается в том, что Linux не защищает вас от вас самих.

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

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

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

/users/terdon

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

/home/localuser

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

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

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

Системы 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, найденным для их записи в этом файле, UID сопоставляются с первым именем пользователя, найденным в этом файле.

Но то, что вы создали, - это запутанная ситуация для других администраторов систем; избежать этого, изменив UIDtest13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

От APUE , §8.15:

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

....

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

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