Несколько *ОТКЛОНЯЮТ учетные записи с идентичным UID

Это будет работать над всем Unixes? Да.

Действительно ли это - хорошая техника для использования? Нет. Существуют другие методы, которые лучше. Например, надлежащее использование групп Unix и строго управляемых "sudo" конфигураций может достигнуть того же самого.

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

Эта способность разработана, или это - просто способ, которым это, оказывается, работает?

Разработанный тот путь.

Будет это последовательное через *отклоняет варианты?

Это должно, да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я также не знаю, является ли это хорошая идея или нет, но я использую вышеупомянутое поведение в нескольких местах. Главным образом это для учетных записей что, где используется для доступа к ftp/sftp серверу и обновления содержания веб-сайта. Это, казалось, ничего не повредило и, казалось, сделало обработку полномочий легче затем, что это будет с несколькими учетными записями.

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

Существует одна проблема, о которой я знаю. Крон не играет хорошо с этим искажением UID. Попытайтесь работать "crontab-i" из сценария Python для обновления записей крона. Затем выполненный "crontab-e" в оболочке для изменения того же.

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

BTW -- этот вопрос/ответ обновлен для сегодняшней операционной системы.

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

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

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

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

Проблема возникает, когда понятие "первый" плохо определено. В зависимости от установленного сервиса, имена пользователей могут храниться в хэше переменного размера, который возвращает другое имя пользователя, основанное на несовместимых факторах. (Я знаю, что это правда, так как я иногда пытался использовать 2 имени пользователя w/one ID, одно из которых является локальным именем пользователя, а другое - именем пользователя domain.username, которое я хотел сопоставить с UID (к которому я в конце концов обратился совершенно по-другому), но я мог бы войти в систему с помощью "usera", сделать "who" или "id" и посмотреть "userb" или "usera" - случайным образом.

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

В Sun (теперь oracle) yp(желтые страницы) или NIS(NetworkInformationServices) также есть много ссылок на требования уникальности. Настраиваются специальные функции и серверы для выделения уникальных ID на нескольких серверах и доменах (пример: uid_allocd, gid_allocd - UID и GID allocator daemons manpage

Третьим источником, который можно проверить, является документация Microsoft по серверам для NFS Account Mapping. NFS является протоколом совместного использования файлов unix и описывает, как разрешения и доступ к файлам поддерживаются идентификатором. Там написано:

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

• GID. Это беззнаковое целое число, используемое ядром UNIX для идентификации группы и должны быть уникальными в файле группы. MS-NFS-management page

Хотя некоторые операционные системы, возможно, допускают множественные имена/UID (возможно, производные BSD?), большинство операционных систем зависят от того, что они уникальны и могут вести себя непредсказуемо, когда они таковыми не являются.

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

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

В моем случае, поставщик установил сервер базы данных Informix и сервер веб-приложений на RHEL 7. Во время установки были созданы несколько «корневых» учетных записей с UID 0 (не спрашивайте меня, почему). То есть, «root», «user1» и «user2», все имеют UID 0.

Сервер RHEL 7 позже был присоединен к домену Active Directory с помощью winbind. На этом этапе сервер Informix DB больше не может запускаться. Выполнение oninit завершалось ошибкой с сообщением об ошибке «Для запуска этой программы должен быть DBSA» .

Вот что мы обнаружили во время устранения неполадок:

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 может запускаться.

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