Чому я можу створювати користувачів з тим самим 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матиме привілеї, як кореневий рахунок?

Відповідь тут полягає в тому, що Linux не захищає вас від себе.

Якщо ви дійсно хочете su rootзайти у файли / etc та надати всім користувачам однаковий UID, ви можете. Це просто текстовий файл.

Але ви справді не повинні, і це матиме ненавмисні наслідки.

Для цього є фактично поважні причини. Наприклад, я працював у лабораторії, де кожен з нас мав власний комп'ютер, але наш $HOMEзнаходився на спільному диску, експортованому сервером. Отже, моя $HOMEбула

/users/terdon

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

/home/localuser

Однак мені потрібен був повний доступ до моїх файлів, незалежно від того, чи я входив як terdonабо як, localuserі те, як реалізував наш sysadmin, надаючи 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Файл відображає призначені для користувача імена для призначених для користувача ідентифікаторів (номера) і в прикладі ви повинні забезпечити, ви просто зіставляються два імені користувача з тим же ідентифікатором користувача.

Фактично, ви створили одного користувача test12ID 1005, який також має друге ім’я користувача test13. Однак система відобразить UID 1005 на перше знайдене ім'я користувача, яке було бtest12

Linux "дозволяє" вам це зробити, тому що не існує системи, яка б заважала вам це робити. /etc/passwdце лише текстовий файл, імена користувачів відображаються в UID, знайденому для їх запису в цьому файлі, UID-карти відображаються на перше ім’я користувача, знайдене в цьому файлі.

Але те, що ви створили, - заплутану ситуацію для інших адміністраторів систем; уникнути цього, змінивши UIDtest13

Причина того, що це сьогодні дозволено, полягає просто в тому, що система не перешкоджає цьому.

Якщо це змінилося, то воно порушило б ті системи, де адміністратори використовували цю функцію (див. Приклад Тердона). Тож воно ніколи не змінювалося, і я не думаю, що це колись буде.

Спочатку існували лише файли passwd та group, і вони виконували своє призначення. не було команди adduser , ніякої групи , файли редагувались root за допомогою vi або ed.

Було кілька примх!

Для того, щоб запам'ятати наступний ідентифікатор користувача, який використовується, для адміністраторів було звичайним користувачем, як останній рядок, який мав ім'я користувача !(оскільки це !було недійсне ім'я користувача), і цей запис використовувався для зберігання наступного ідентифікатор користувача. Сирий, я визнаю, але це спрацювало! То чому б розбити кишку, ускладнивши її, схожу на спритний розвиток сьогодні.

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

Деякі системи Unix почали впроваджувати пару скриптів оболонок adduser addgroup, часто їх ігнорували, оскільки вони були непослідовними між Unixes, тому більшість людей просто продовжували редагування вручну.

Минуло досить багато років, перш ніж shadowбув винайдений файл пароля, це забезпечило трохи більше безпеки, приховавши зашифровані паролі. Знову ж таки, було додано достатньо складності, але вона все ще була досить сирою і простою. Утиліти useraddі groupaddбули введені, які зберігаються shadowі shadow-оновлюються. Для початку це були найчастіше прості обгортки скриптів оболонки навколо фірмових утиліт adduser / addgroup постачальників . Знову це було достатньо, щоб продовжувати.

Мережі комп'ютерів зростали, люди працювали над декількома часом, щоб виконати роботу, тому адміністратор passwd/groupфайлів став кошмаром, особливо з NFS, так що Yellow Pages також відомий як NIS, щоб полегшити тягар.

На сьогодні вже стало очевидним, що потрібно щось дещо гнучкіше, і PAM був винайдений. Тож якби ви були справді витонченими і хотіли централізованої, захищеної, унікальної ідентифікації, усі системи аутентифікації дзвінків і свистків, ви зателефонували б на центральний сервер для автентифікації, можливо сервер Radius, сервер LDAP або активний каталог.

Світ виріс. Але файли passwd / group / тіні все ще залишалися для нас меншими користувачами / розробниками / лабораторіями. Ми все ще не дуже потребували всіх дзвіночків. Я думаю, що філософія до цього часу трохи змінилася на "Якби ти збирався зробити це кращим, ти б взагалі не користувався ним" , тому не турбуйся про це.

Ось чому я не думаю, що простий файл passwd ніколи не зміниться. Більше немає сенсу, і це просто чудово для тих £ 30 Raspberry Pi з 2, можливо, 3-х моніторинговою температурою та твітер-каналами. Гаразд, вам потрібно бути трохи обережними зі своїми ідентифікаторами користувачів, якщо ви хочете, щоб вони були унікальними, і ніщо не заважає ентузіасту загортати useradd у сценарій, який спочатку вибирає наступний унікальний ідентифікатор з бази даних (файлу) для встановлення унікальний ідентифікатор, якщо ви цього хочете. Адже це з відкритим кодом.

/etc/passwdФайл просто відображає символічні імена користувачів в реальний ідентифікатор користувача. Якщо ви навмисно зробите два символічні імена, які позначаються на одному ідентифікаторі користувача, це дозволить вам.

Це не означає, що це дійсно добре зробити. Деякі люди, можливо, знайшли дуже специфічні випадки використання, коли вони можуть скористатися цією функцією, але взагалі не варто цього робити.

Linux (та інші UNIX) вважають, що адміністратор знає, що вони роблять. Якщо ви скажете йому зробити щось дурне, то це сама ваша вина, так само, як якщо ви скажете своєму автомобілю проїхати по скелі, ви не можете піти до виробників і запитати, чому машина дозволила вам це зробити.

Існують ідентифікатори, які операційна система очікує на унікальність, але вони використовуються для відстеження апаратних засобів. Знання, яке конкретна Універсально унікальному ідентифікатору відповідає жорсткий диск, що містить системні файли, може допомогти йому продовжувати працювати, якщо конфігурація обладнання зміниться. Microsoft називає ці глобально унікальні ідентифікатори і використовує їх для відстеження всього програмного забезпечення Windows. Як не дивно, ці абревіатури були обрані погано.

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

Я знайшов деякі докази, які підтверджують відповідь @ andybalholm.

З APUE , § 8.15:

Будь-який процес може дізнатися його реальний та ефективний ідентифікатор користувача та ідентифікатор групи. Однак іноді ми хочемо дізнатись ім’я для входу користувача, який виконує програму. Ми можемо зателефонувати getpwuid( getuid()), але що робити, якщо один користувач має кілька імен для входу, кожне з однаковим ідентифікатором користувача? ( У людини може бути кілька записів у файлі паролів з тим самим ідентифікатором користувача, щоб мати різні оболонки для входу для кожного запису .) Система зазвичай відстежує ім’я, під яким ми входимо (Розділ 6.8), іgetlogin функція забезпечує спосіб отримати це ім’я для входу.

….

Враховуючи ім’я для входу, ми можемо використовувати його для пошуку користувача у файлі пароля - щоб визначити оболонку входу, наприклад, використовуючи getpwnam.

До речі, я хотів би знати, чи можна перейти на іншу оболонку під час входу.