Мне любопытно, существует ли стандартное ожидаемое поведение и считается ли это плохой практикой при создании более одной учетной записи в Linux / Unix с одинаковым UID. Я провел несколько тестов на RHEL5, и он вел себя так, как я ожидал, но я не знаю, искушаю ли я судьбу этим трюком.
В качестве примера предположим, что у меня есть две учетные записи с одинаковыми идентификаторами:
a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash
Это значит:
Итак, мои вопросы:
Обратите внимание, что идея здесь состоит в том, чтобы использовать это для системных учетных записей, а не для обычных учетных записей пользователей.
Мое мнение:
Эта способность задумана или просто так работает?
Он разработан. С тех пор, как я начал использовать * NIX, вы можете размещать пользователей в общих группах. Возможность без проблем иметь одинаковый UID - это всего лишь предполагаемый результат, который, как и все остальное, может вызвать проблемы при неправильном управлении.
Будет ли это согласовываться между вариантами * nix?
Я так считаю.
Это общепринятая практика?
Принято, поскольку обычно так или иначе используется, да.
Есть ли у этой практики непредвиденные последствия?
У вас нет ничего, кроме аудита входа в систему. Если только вы не хотели именно этого, для начала.
Будет ли он работать на всех Unix? Да.
Это хорошая техника? Нет. Есть другие методы, которые лучше. Например, правильное использование групп unix и строго контролируемых конфигураций «sudo» позволяет добиться того же.
Я видел ровно одно место, где это использовалось без проблем. Во FreeBSD традиционно создается вторая учетная запись root с именем «toor» (корень, записанный в обратном порядке), который имеет / bin / sh в качестве оболочки по умолчанию. Таким образом, если оболочка root не работает, вы все равно можете войти в систему.
Я не могу дать канонического ответа на ваши вопросы, но, как показывает практика, моя компания уже много лет делает это с пользователем root и никогда не сталкивается с какими-либо проблемами. Мы создаем пользователя kroot (UID 0), единственная причина существования которого - иметь / bin / ksh в качестве оболочки вместо / bin / sh или bin / bash. Я знаю, что наши администраторы баз данных Oracle делают что-то подобное со своими пользователями, имея 3 или 4 имени пользователя на установку, все с одинаковыми идентификаторами пользователей (я считаю, что это было сделано для того, чтобы иметь отдельные домашние каталоги для каждого пользователя. Мы делаем это как минимум десять лет на Solaris и Linux. Я думаю, он работает так, как задумано.
Я бы не стал этого делать с учетной записью обычного пользователя. Как вы заметили, после первоначального входа в систему все возвращается к первому имени в файле журнала, поэтому я думаю, что действия одного пользователя могут быть замаскированы под действия другого в журналах. Хотя для системных учетных записей он отлично работает.
Есть ли у этой практики непредвиденные последствия?
Есть одна проблема, о которой я знаю. Cron плохо работает с этим псевдонимом UID. Попробуйте запустить crontab -i из сценария Python, чтобы обновить записи cron. Затем запустите «crontab -e» в оболочке, чтобы изменить то же самое.
Обратите внимание, что теперь cron (я думаю, vixie) обновит одни и те же записи для a1 и a2 (в / var / spool / cron / a1 и / var / spool / cron / a2).
Эта способность задумана или просто так работает?
Создан таким образом.
Будет ли это согласовываться между вариантами * nix?
Должен, да.
Это общепринятая практика?
Зависит от того, что вы имеете в виду. Этот тип вещей решает чрезвычайно конкретную проблему (см. Учетные записи root / toor). Где-нибудь еще, и вы задаетесь глупой проблемой в будущем. Если вы не уверены, что это правильное решение, скорее всего, это не так.
Есть ли у этой практики непредвиденные последствия?
Обычно принято рассматривать имена пользователей и UID как взаимозаменяемые. Как указали несколько других людей, аудит входа / активности будет неточным. Вы также захотите просмотреть поведение любых соответствующих пользовательских сценариев / программ (сценарии useradd, usermod, userdel вашего дистрибутива, любые сценарии периодического обслуживания и т. Д.).
Что вы пытаетесь сделать с этим, чего не удалось бы достичь, добавив этих двух пользователей в новую группу и предоставив этой группе необходимые вам разрешения?
Это ожидаемое поведение во всех дистрибутивах, которые я видел, и это обычная уловка, которую «враг» использует, чтобы скрыть учетные записи с корневым доступом.
Это, конечно, нестандартно (я нигде не видел этого в игре), но не должно быть никаких причин, по которым вы не можете использовать это в своей собственной среде, если считаете нужным.
Единственная ошибка, которая приходит в голову прямо сейчас, - это то, что это может затруднить одитинг. Если у вас есть два пользователя с одним и тем же uid / gid, я считаю, что вам будет сложно понять, какой из них что сделал, когда вы анализируете журналы.
Совместное использование идентификаторов основных групп является обычным явлением, поэтому вопрос действительно вращается вокруг UID.
Я делал это раньше, чтобы дать кому-нибудь root-доступ, без необходимости разглашать пароль root - что хорошо сработало. (хотя, думаю, лучше было бы sudo)
Главное, к чему я был бы осторожен, это такие вещи, как удаление одного из пользователей - программы может запутаться и удалить обоих пользователей или файлы, принадлежащие обоим, или похожие вещи.
На самом деле я думаю, что программисты наверняка Предположим, что соотношение 1: 1 между пользователем и UID, поэтому вполне могут возникнуть неожиданные последствия с другими программами, подобными тому, что я описал для userdel.
Кстати - этот вопрос / ответ обновлен для сегодняшних ОС.
Цитата из redhat: управление назначениями уникальных UID и GID номеров, в нем описывается использование UID и GID и их управление, а также как генераторы (серверы идентификаторов)
должен генерировать случайные значения UID и GID и одновременно гарантировать, что реплики никогда не будут генерировать одно и то же значение UID или GID. Потребность в уникальных номерах UID и GID может даже пересекать домены IdM, если одна организация имеет несколько разнородных доменов.
Точно так же утилиты, разрешающие доступ к системе, могут вести себя непредсказуемо (та же ссылка):
Если двум записям назначен один и тот же идентификационный номер, при поиске этого номера возвращается только первая запись.
Проблема возникает, когда понятие «первый» неправильно определено. В зависимости от установленной службы имена пользователей могут храниться в хэше переменного размера, который может возвращать другое имя пользователя в зависимости от несовместимых факторов. (Я знаю, что это правда, так как я иногда пытался использовать 2 имени пользователя с одним идентификатором, одно из которых было локальным именем пользователя, а другое - domain.username, которое я хотел сопоставить с UID (к которому я в конечном итоге обратился в совершенно другой способ), но я мог войти в систему с помощью «usera», ввести «who» или «id» и увидеть «userb» ИЛИ «usera» - случайным образом.
Существует интерфейс для получения нескольких значений UID из группы (группы с одним GID предназначены для связывания с несколькими UID), но нет переносимого интерфейса для возврата списка имен для одного UID, поэтому любой, кто ожидает того же или аналогичное поведение между системами или даже приложениями в одной и той же системе могут быть неприятно удивлены.
В Sun (теперь oracle) yp (желтые страницы) или NIS (NetworkInformationServices) также есть много ссылок на требования уникальности. Специальные функции и серверы настроены для выделения уникальный ID на нескольких серверах и доменах (например, uid_allocd, gid_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 DB больше не может запускаться. Бег oninit не работал с сообщением об ошибке, в котором говорилось, что один "Must be a DBSA to run this program".
Вот что мы обнаружили при устранении неполадок:
Бег id root или getent passwd 0 (чтобы преобразовать UID 0 в имя пользователя) в системе, присоединенной к Active Directory, будет случайным образом возвращать либо «user1», либо «user2» вместо «root».
По-видимому, Informix полагался на сравнение строк, чтобы проверить, является ли текстовое имя пользователя, запустившего его, «root», и в противном случае не удалось бы.
Без winbind, id root и getent passwd 0 будет последовательно возвращать "root" в качестве имени пользователя.
Исправление заключалось в отключении кеширования и сохранения в /etc/nscd.conf:
enable-cache passwd no
persistent passwd no
После этого изменения UID 0 снова постоянно разрешается как «root», и Informix может запускаться.
Надеюсь, это будет кому-то полезно.