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


37

Я понимаю, что 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?


Не уверен насчет этого, но я думаю, что вывод выводит UID пользователя "test10" в обеих командах. Зачем это делать, я понятия не имею, но должен быть какой-то пользователь, которого вы создали ранее.
animaletdesequia

как будто говорят, что есть пользователь с таким идентификатором
nux

ОК, я неправильно понял вопрос. Я думал, что вы создали пользователей нормально, и система присвоила им один и тот же UID.
animaletdesequia

нет человека не нормально, вопрос тут, как система принимает уникальные uids
nux

Понял. Хороший вопрос тогда, спасибо за объяснение :)
animaletdesequia

Ответы:


40

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

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

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


4
мой вопрос почему система принимает это?
nux

46
Что значит "принять" это? Как бы он НЕ принял это? это все равно что быть поваром и спрашивать, почему суп позволил вам добавить в него слишком много соли. С точки зрения современных вычислений, вы, вероятно, привыкли к менталитету РСУБД, где ограничения на такие важные вещи, как идентификаторы, не позволяют вам выстрелить себе в ногу. Идентификаторы пользователей Linux гораздо более примитивны и не имеют внутренней проверки или исправления.
Digital Chris

5
Правильно, и с помощью useradd -oвы узнаете, что вы вне нормы adduser. Как упомянуто @psusi, он создает два имени входа, указывающие на один и тот же идентификатор в отношении прав доступа к файлу и т. Д. Это, вероятно, также создает проблемы, поскольку это не является нормальным вариантом использования и, без сомнения, не проверялось с большим количеством пакетов.
Цифровой Крис

2
Ответ: чтобы два логина указывали на одинаковые разрешения файловой системы.
Digital Chris

5
@ Конечно, есть веские причины иметь несколько пользователей с одинаковым UID, см. Мой ответ для одного примера.
Тердон

38

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

/users/terdon

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

/home/localuser

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


6
В поддержку этого ответа стоит отметить, что некоторые настройки, такие как виртуальный почтовый хостинг, используют это с большим эффектом, то есть большое количество виртуальных учетных записей электронной почты, использующих один и тот же UID - документация для почтового сервера Dovecot фактически предлагает это как дополнительный подход на wiki2.dovecot.org/UserIds#mailusers
Мэтт Томасон

не будет chmod 666иметь такие же аффекты?
Брайан

3
@GIJoe, который позволил бы обоим пользователям читать / писать, но не сохранял бы право собственности, что могло быть проблемой. Кроме того, не всем файлам могут быть назначены эти разрешения (например, ssh-ключи), и нецелесообразно постоянно играть с разрешениями.
Terdon

12

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


как система взаимодействует с пользователями тогда? разрешения на совместное использование
nux

12
@nux, они оба один и тот же пользователь. Они могут просто иметь другое имя пользователя / пароль для входа в систему.
psusi

4
@ bigbadonk420, термин «поддерживается» довольно туманный. Это, безусловно, то, что вы всегда могли делать в Unix-системах, и это был довольно распространенный бэкдор для настройки другого пользователя с uid 0, чтобы вы могли войти в систему и эффективно работать в качестве пользователя root без необходимости знать или менять пароль. на обычного пользователя root.
psusi

1
@ bigbadonk420 это поддерживается, есть случаи, когда это полезно, см. мой ответ для одного примера.
Terdon

11

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


11

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


9

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

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

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

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

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


это мой тестовый виртуальный человек, мой вопрос, есть ли цель сопоставить двух пользователей для одного и того же uid
nux

1
Единственная цель, о которой я могу подумать - дать UID второе, псевдонимное имя пользователя. Но это неопределенное поведение и не рекомендуется. На самом деле это нежелательная ситуация: вам лучше иметь соотношение 1: 1 между именами пользователей и UID
Джош,

вот почему я задал этот вопрос, который мне нужно было знать, я чувствовал, что это сбивает с толку
nux

Это сбивает с толку; вот почему ты не должен этого делать. У него нет «цели», это скорее злоупотребление /etc/passwdфайлом. Но нет никаких средств, чтобы помешать вам сделать это. Имеет ли это смысл?
Джош

1
пользователь упомянул, что цель состоит в том, чтобы 2 входа в систему указывали на идентичные разрешения файловой системы.
NUX

5

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

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


2

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

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

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


почему это было упомянуто как ошибка?
NUX

1

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

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


0

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

От APUE , §8.15:

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

....

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.