Несколько учетных записей * 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 испорчена, вы можете войти в систему.

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

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

Эта способность разработана или это просто так, как это происходит?

Разработан таким образом.

Это будет согласовано между * nix вариантами?

Должно, да.

Это принятая практика?

Зависит от того, что вы имеете в виду. Этот тип вещей решает чрезвычайно специфическую проблему (см. Учетные записи root / toor). В другом месте, и вы просите глупую проблему в будущем. Если вы не уверены, что это правильное решение, скорее всего, это не так.

Есть ли непредвиденные последствия для этой практики?

Обычно считается, что имена пользователей и UID взаимозаменяемы. Как отметили несколько других людей, аудит входа / активности будет неточным. Вы также можете проверить поведение любых соответствующих пользовательских скриптов / программ (useradd, usermod, userdel, скрипты периодического обслуживания и т. Д. Вашего дистрибутива).

Что вы пытаетесь сделать с помощью этого, чего нельзя достичь, добавив этих двух пользователей в новую группу и предоставив этой группе необходимые вам разрешения?

Есть ли непредвиденные последствия для этой практики?

Есть одна проблема, о которой я знаю. Cron плохо играет с этим псевдонимом UID. Попробуйте запустить "crontab -i" из скрипта Python для обновления записей cron. Затем запустите «crontab -e» в оболочке, чтобы изменить то же самое.

Обратите внимание, что теперь cron (я думаю, vixie) обновил те же записи для a1 и a2 (в / var / spool / cron / a1 и / var / spool / cron / a2).

Это ожидаемое поведение во всех дистрибутивах, которые я видел, и это обычная уловка, которую «враг» использует, чтобы скрыть учетные записи с root-доступом.

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

Единственное, что приходит в голову сейчас - это может затруднить одитинг. Если у вас есть два пользователя с одинаковыми uid / gid, я думаю, вам будет сложно выяснить, кто что делал, когда анализировал логи.

Совместное использование идентификаторов первичных групп является обычным делом, поэтому вопрос действительно вращается вокруг UID .

Я делал это раньше, чтобы дать кому-нибудь root-доступ без необходимости разглашения пароля root - что сработало хорошо. (хотя sudo был бы лучшим выбором, я думаю)

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

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

Кстати - этот вопрос / ответ обновлен для сегодняшних ОС.

Цитата из redhat: управление уникальными назначениями номеров UID и GID , в нем описывается использование UID и GID и их управление, а также методы работы генераторов (серверов ID)

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

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

Если двум записям присваивается один и тот же идентификационный номер, при поиске этого номера возвращается только первая запись.

Проблема возникает, когда понятие «первый» плохо определено. В зависимости от установленной службы имена пользователей могут храниться в хэше переменного размера, который будет возвращать другое имя пользователя в зависимости от несовместимых факторов. (Я знаю, что это правда, поскольку я иногда пытался использовать 2 имени пользователя с одним идентификатором, одно из которых было локальным именем пользователя, а другое - именем domain.user, которое я хотел сопоставить с UID (к которому я в конечном итоге обратился в совершенно другим способом), но я мог войти в систему с помощью «usera», сделать «who» или «id» и увидеть «userb» ИЛИ «usera» - случайно.

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

В Sun (теперь oracle) yp (желтые страницы) или NIS (NetworkInformationServices) также имеется много ссылок на требования уникальности. Специальные функции и серверы настроены для распределения уникальных идентификаторов по нескольким серверам и доменам (например, man-страница демонов распределителя uid_allocd - UID и GID).

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

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

• GID. Это целое число без знака, используемое ядром 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, очевидно, полагался на сравнение строк, чтобы проверить, было ли текстовое имя пользователя, запустившего его, «корневым» и в противном случае не получилось бы.

3. Без winbind, id rootи getent passwd 0будет последовательно возвращать «root» в качестве имени пользователя.

Исправление было отключить кэширование и сохранение в /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

После этого изменения UID 0 снова постоянно преобразовывался в «root», и Informix мог запускаться.

Надеюсь, это будет кому-то полезно.