Мне интересно, существует ли стандартное ожидаемое поведение и считается ли плохой практикой создание более одной учетной записи в 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?
Является ли это общепринятой практикой?
Есть ли у этой практики непредвиденные последствия?
Обратите внимание, идея здесь в том, чтобы использовать это для системных учетных записей, а не для обычных учетных записей пользователей.
Ответ 1
Мое мнение:
Надумана ли эта возможность или это просто способ, которым она работает?
Надумана. С тех пор, как я начал использовать *NIX, стало возможным помещать пользователей в общие группы. Возможность иметь одинаковый UID без проблем — это просто запланированный результат, который, как и все остальное, может принести проблемы при неправильном управлении.
Будет ли это одинаково для всех вариантов *nix?
Думаю, да.
Является ли это общепринятой практикой?
Принятая в смысле общепринятая в том или ином виде, да.
Есть ли у этой практики непредвиденные последствия?
Кроме аудита входа в систему, у вас больше ничего нет. Если только вы не хотели именно этого с самого начала.
Ответ 2
Я не могу дать канонический ответ на ваши вопросы, но, по моим данным, моя компания уже много лет делает это с пользователем root и никогда не испытывала никаких проблем. Мы создаем пользователя «kroot» (UID 0), единственная причина существования которого заключается в том, чтобы иметь /bin/ksh в качестве оболочки вместо /bin/sh или bin/bash. Я знаю, что наши DBA Oracle делают нечто подобное со своими пользователями, имея 3 или 4 имени пользователей на установку, все с одинаковыми идентификаторами пользователей (я полагаю, это было сделано для того, чтобы иметь отдельные домашние каталоги для каждого пользователя). Мы делаем это уже как минимум десять лет, на Solaris и Linux. Я думаю, что все работает так, как задумано.
Я бы не стал делать этого с учетной записью обычного пользователя. Как вы отметили, после первого входа в систему все возвращается к первому имени в файле журнала, поэтому я думаю, что действия одного пользователя могут быть замаскированы под действия другого в журналах. Однако для системных учетных записей это работает отлично.
Ответ 3
Обмен идентификаторами первичных групп — обычное дело, поэтому вопрос действительно вращается вокруг UID. Я уже делал это раньше, чтобы дать кому-то доступ root без необходимости разглашать пароль root, и это сработало хорошо (хотя sudo был бы лучшим выбором, я думаю).
Главное, с чем я бы поостерегся, — это с удалением одного из пользователей. Программа может запутаться и удалить обоих пользователей или файлы, принадлежащие обоим, или что-то подобное. На самом деле, я думаю, что программисты, вероятно, предполагают соотношение 1:1 между пользователем и UID, поэтому вполне возможны неожиданные последствия для других программ, подобные тем, что я описал для userdel.
Ответ 4
Кстати, этот вопрос/ответ был обновлен для современных ОС.
Цитируя из redhat:
management unique UID and GID Number assignments, здесь описывается использование UID и GID и управление ими, а также то, как генераторы (серверы ID) должны генерировать случайные значения UID и GID и одновременно обеспечивать, чтобы реплики никогда не генерировали одинаковые значения UID или GID. Необходимость в уникальных номерах UID и GID может даже пересекаться с IdM доменами, если одна организация имеет несколько разрозненных доменов.
Аналогично утилиты, обеспечивающие доступ к системе, могут вести себя непредсказуемо:
Если двум записям присвоен одинаковый идентификационный номер, то при поиске по этому номеру возвращается только первая запись.
Проблема возникает, когда понятие «первый» плохо определено. В зависимости от установленной службы, имена пользователей могут храниться в хеше переменного размера, который будет возвращать разные имена пользователей на основе несовместимых факторов (я знаю, что это так, поскольку иногда я пытался использовать 2 имени пользователя с одним ID, одно из которых было локальным именем пользователя, а другое — именем пользователя domain.username, которое я хотел сопоставить с UID — которое я в итоге решил совершенно другим способом, — но я мог войти в систему под именем «usera», сделать запрос «who» или «id» и увидеть «userb» или «usera» — случайным образом).
Существует интерфейс для извлечения нескольких значений UID из группы (группы с одним GID предназначены для ассоциирования с несколькими UID), но нет переносимого интерфейса для возврата списка имен для одного UID, поэтому тот, кто ожидает такого же или похожего поведения между системами или даже приложениями на одной системе, может быть неприятно удивлен.
В Sun (теперь oracle) yp (yellowpages) или NIS (NetworkInformationServices) также есть много ссылок на требования уникальности. Специальные функции и серверы настроены на выделение уникальных идентификаторов для нескольких серверов и доменов (примером могут служить uid_allocd, gid_allocd - UID и GID allocator daemons manpage).
Третьим источником, который можно проверить, является документация Microsoft по серверу для NFS Account Mapping. NFS — это протокол обмена файлами unix, и они описывают, как разрешения на файлы и доступ к ним поддерживаются идентификатором. Там они пишут:
UID. Это целое число без знака, которое используется операционными системами UNIX для идентификации пользователей и должно быть уникальным в файле passwd.
GID. Это целое число без знака, которое используется ядром UNIX для идентификации групп и должно быть уникальным в файле group. Страница MS-NFS-management.
Хотя некоторые ОС могут разрешать несколько имен/UID (производные BSD, возможно?), большинство ОС зависит от уникальности этого имени и может вести себя непредсказуемо, когда это не так.
Ответ 5
Только что столкнулся с (довольно неясной) проблемой, связанной с использованием нескольких учетных записей с одним и тем же UID, и решил поделиться ею в качестве примера того, почему это не очень хорошая практика.
В моем случае поставщик устанавливал сервер базы данных Informix и сервер веб-приложений на RHEL 7. Во время установки было создано несколько учетных записей «root» с UID 0 (не спрашивайте меня почему). То есть «root», «user1» и «user2», все с UID 0.
Позже сервер RHEL 7 был подключен к домену Active Directory с помощью winbind. В этот момент сервер Informix DB больше не мог запуститься. Запуск oninit завершался неудачей с сообщением об ошибке: «Для запуска этой программы необходимо быть DBSA».
Вот что мы обнаружили во время поиска неисправностей:
Запуск 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 смог запуститься. Надеюсь, это будет кому-то полезно.
Linux