Мне любопытно, существует ли стандартное ожидаемое поведение и считается ли это плохой практикой при создании более одной учетной записи в 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 вариантами?
- Это принятая практика?
- Есть ли непредвиденные последствия для этой практики?
Обратите внимание, что идея заключается в том, чтобы использовать это для системных учетных записей, а не обычных учетных записей пользователей.
Будет ли это работать на всех 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)
Точно так же утилиты, которые разрешают доступ к системе, могут вести себя непредсказуемо (та же ссылка):
Проблема возникает, когда понятие «первый» плохо определено. В зависимости от установленной службы имена пользователей могут храниться в хэше переменного размера, который будет возвращать другое имя пользователя в зависимости от несовместимых факторов. (Я знаю, что это правда, поскольку я иногда пытался использовать 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"
.Вот что мы нашли при устранении неисправностей:
Выполнение
id root
илиgetent passwd 0
(для преобразования UID 0 в имя пользователя) в присоединенной системе Active Directory случайным образом возвращает либо «user1», либо «user2», а не «root».Informix, очевидно, полагался на сравнение строк, чтобы проверить, было ли текстовое имя пользователя, запустившего его, «корневым» и в противном случае не получилось бы.
Без winbind,
id root
иgetent passwd 0
будет последовательно возвращать «root» в качестве имени пользователя.Исправление было отключить кэширование и сохранение в
/etc/nscd.conf
:После этого изменения UID 0 снова постоянно преобразовывался в «root», и Informix мог запускаться.
Надеюсь, это будет кому-то полезно.
источник