Кілька * NIX облікових записів з ідентичним UID

Мені цікаво, чи є стандартна очікувана поведінка і чи вважається це поганою практикою при створенні декількох облікових записів в Linux / Unix, які мають однаковий UID. Я зробив кілька тестів на RHEL5 з цим, і він поводився так, як я очікував, але я не знаю, чи спокушаю долю, використовуючи цей трюк.

Скажімо, у мене є два облікові записи з однаковими ідентифікаторами:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

Що це означає:

• Я можу увійти до кожного облікового запису, використовуючи власний пароль.
• Файли, які я створюю, матимуть однаковий UID.
• Такі інструменти, як "ls -l", перелічать UID як перший запис у файлі (a1 у цьому випадку).
• Я уникаю будь-яких дозволів чи проблем із власністю між двома обліковими записами, оскільки вони справді однакові користувачі.
• Я отримую аудит входу для кожного облікового запису, тому я маю кращу детальність щодо відстеження того, що відбувається в системі.

Отже, мої запитання:

• Чи розроблена ця здатність чи це просто так, як це відбувається?
• Це буде узгоджено для * nix варіантів?
• Це прийнята практика?
• Чи є ненавмисні наслідки для цієї практики?

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

Моя думка:

Чи розроблена ця здатність чи це просто так, як це відбувається?

Він розроблений. З того часу, як я почав використовувати * NIX, ви змогли розмістити користувачів на загальних групах. Можливість мати однаковий UID без проблем - це лише намічений результат, який, як і все, може призвести до проблем при неправильному керуванні.

Це буде узгоджено для * nix варіантів?

Я так думаю.

Це прийнята практика?

Так прийнято, як правило, так чи інакше використовується, так.

Чи є ненавмисні наслідки для цієї практики?

Крім аудиту входу, у вас нічого більше немає. Якщо тільки ви цього не хотіли, для початку.

Чи буде це працювати на всіх Unixes? Так.

Це хороша техніка використання? Ні. Є інші методи, які краще. Наприклад, правильне використання груп Unix і суворо керовані конфігурації "sudo" можуть досягти одних і тих же речей.

Я бачив саме одне місце, де це було використано без проблем. У FreeBSD традиційно створювати другий кореневий обліковий запис під назвою "toor" (root написано назад), який має / bin / sh як оболонку за замовчуванням. Таким чином, якщо оболонка кореня зіпсується, ви все одно можете увійти.

Я не можу надати канонічну відповідь на ваші запитання, але анекдотично моя компанія займається цим роками з користувачем root і ніколи з цим не виникала жодних проблем. Ми створюємо користувача "kroot" (UID 0), єдиною причиною існування якого є / bin / ksh як оболонка замість / bin / sh або bin / bash. Я знаю, що наші Oracle DBA роблять щось подібне зі своїми користувачами, маючи 3 або 4 імені користувача на інсталяцію, всі з однаковими ідентифікаторами користувачів (я вважаю, що це було зроблено, щоб мати окремі домашні каталоги з кожним користувачем. Ми робимо це принаймні Десять років, на Solaris і Linux, я думаю, що це працює так, як було розроблено.

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

Чи розроблена ця здатність чи це просто так, як це відбувається?

Створений таким чином.

Це буде узгоджено для * nix варіантів?

Слід, так.

Це прийнята практика?

Залежить від того, що ви маєте на увазі. Цей тип речі відповідає на надзвичайно конкретну проблему (див. Акаунти root / toor). В іншому місці, і ви запитуєте дурну проблему в майбутньому. Якщо ви не впевнені, чи це правильне рішення, можливо, це не так.

Чи є ненавмисні наслідки для цієї практики?

Загальний звичай трактувати імена користувачів та UID як взаємозамінні. Як зауважило декілька інших людей, аудит реєстрації / діяльності буде неточним. Ви також хочете переглянути поведінку будь-яких відповідних сценаріїв / програм, пов’язаних з користувачем (useradd вашого дистрибутива, usermod, сценарії користувачів, будь-які сценарії періодичного обслуговування тощо).

Що ви намагаєтеся зробити з цим, що не вдалося б досягти, додавши цих двох користувачів до нової групи та надавши цій групі потрібні дозволи?

Чи є ненавмисні наслідки для цієї практики?

Є одне питання, яке мені відомо. Cron не грає добре з цим псевдонімом UID. Спробуйте запустити "crontab -i" зі сценарію Python, щоб оновити записи cron. Потім запустіть "crontab -e" в оболонці, щоб змінити те саме.

Зауважте, що зараз cron (vixie, я думаю) оновив би однакові записи для a1 та a2 (in / var / spool / cron / a1 та / var / spool / cron / a2).

Така очікувана поведінка у всіх дистрибутивах, які я бачив, і це загальна хитрість, яку "ворог" використовує для приховування облікових записів із кореневим доступом.

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

Єдина думка, яка зараз спадає на думку, - це може ускладнити аудит. Якщо у вас є два користувачі з однаковим uid / gid, я вважаю, що вам буде важко розібратися, хто з них зробив, коли ви аналізуєте журнали.

Обмін ідентифікаторами первинної групи є загальним, тому питання справді обертається навколо UID .

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

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

Насправді, я думаю, що програмісти, ймовірно, передбачають зв'язок користувача 1: 1 між користувачем та UID, тому дуже добре можуть бути несподівані наслідки для інших програм, схожих на те, що я описав для userdel.

BTW - це питання / відповідь оновлено для сьогоднішніх ОС.

Цитуючи з redhat: управління унікальними призначеннями UID та GID , він описує використання UID та GID та їх управління та як генератори (сервери ідентифікаторів)

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

Аналогічно, утиліти, які дозволяють отримати доступ до системи, можуть поводитись непередбачувано (та сама посилання):

Якщо двом записам присвоєно однаковий ідентифікаційний номер, у пошуку за цим номером повертається лише перший запис.

Проблема виникає, коли поняття "перший" погано визначене. Залежно від встановленої служби, імена користувачів можуть зберігатися у хеші змінних розмірів, який би повертав інше ім'я користувача на основі непослідовних факторів. (Я знаю, що це правда, тому що я іноді намагався використовувати 2 імена користувачів без одного ідентифікатора, одне - локальне ім'я користувача, а інше - domain.username, яке я хотів відобразити в UID (на який я врешті звернувся в зовсім інший спосіб), але я міг увійти за допомогою "usera", зробити "хто" або "id" і побачити "userb" АБО "usera" - випадковим чином.

Існує інтерфейс для отримання декількох значень UID з групи (групи з одним GID призначені для асоціації з декількома UID), але немає портативного інтерфейсу для повернення списку імен для одного UID, тому кожен, хто очікує того ж або подібна поведінка між системами або навіть додатками в одній системі може бути несподівано здивованою.

У Sun (зараз оракул) yp (yellowpages) або NIS (NetworkInformationServices) також є багато посилань на вимоги унікальності. Спеціальні функції та сервери налаштовані для розподілу унікальних ідентифікаторів на декількох серверах і доменах (наприклад, uid_allocd, gid_allocd - UID та GID-розподільник демонів

Третє джерело, яке можна перевірити, - це документація сервера Microsoft щодо картографування облікових записів NFS. NFS - це протокол обміну файлами unix, який описує, як ідентифікатори підтримують дозволи та доступ до файлів. Там вони пишуть:

• UID. Це ціле число без підпису, яке використовується операційними системами UNIX для ідентифікації користувачів і повинно бути унікальним у файлі passwd.

• ГІД. Це ціле число без підпису, яке використовується ядром UNIX для ідентифікації груп і повинно бути унікальним у файлі групи. Сторінка управління MS-NFS

Хоча деякі ОС можуть дозволити кілька імен / UID (похідні BSD, можливо?), Більшість ОС залежать від того, щоб це було унікальним, і вони можуть вести себе непередбачувано, коли їх немає.

Примітка. Я додаю цю сторінку, як хтось назвав цей датований запис як підтримку сучасних утиліт для розміщення не унікальних UID / GID ... яких більшість, ні.

Я також не знаю, чи це гарна ідея чи ні, але я використовую вищезгадану поведінку в декількох місцях. В основному це стосується облікових записів, які використовуються для доступу до сервера ftp / sftp та оновлення вмісту веб-сайту. Це, здається, нічого не порушило і, здається, полегшило обробку дозволів, ніж це було б із кількома обліковими записами.

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

У моєму випадку постачальник налаштував сервер баз даних Informix та сервер веб-додатків на RHEL 7. Під час налаштування було створено кілька "кореневих" облікових записів з UID 0 (не питайте мене чому). Тобто, "root", "user1" і "user2", усі мають UID 0.

Пізніше сервер RHEL 7 був приєднаний до домену Active Directory за допомогою winbind. У цей момент сервер БД Informix більше не міг запускатися. Запуск oninitбув збій з повідомленням про помилку, що один "Must be a DBSA to run this program".

Ось що ми знайшли під час усунення несправностей:

1. Запуск id rootабо getent passwd 0(щоб вирішити UID 0 на ім’я користувача) в системі, що приєдналася до Active Directory, випадково повертає або "user1", або "user2", а не "root".

2. Informix, мабуть, покладається на порівняння рядків, щоб перевірити, чи є текстове ім'я користувача, який запускається, "root" і не вдасться в іншому випадку.

3. Без winbind, id rootі getent passwd 0послідовно повертає "root" як ім'я користувача.

Виправлення було відключити кешування та збереження в /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Після цієї зміни UID 0 ще раз послідовно вирішив "root" і Informix міг запуститися.

Сподіваюся, це комусь стане в нагоді.