Назад | Перейти на главную страницу

Управление информацией о пользователях и группах для лаборатории с использованием Linux и / home, смонтированных с узла данных

Наша лаборатория состоит из нескольких настольных компьютеров и узла данных, работающих под управлением Ubuntu Linux. Настольные машины монтируются в / домой из узла данных. Файлы и пользователи в / home управляются с помощью UID и GID, хранящихся в файлах / etc / passwd, / etc / group и / etc / shadow. Если я хочу добавить пользователя или группу, мне нужно отредактировать файлы passwd / group / shadow машины данных и скопировать определенные строки во все файлы passwd / group / shadow всех настольных машин.

Есть ли способ заставить Linux использовать несколько файлов passwd / group / shadow? Мы хотим, чтобы настольные машины имели свой собственный пароль / группу / тень, а затем включали пароль / группу / тень от машины данных в качестве дополнения к их собственному.

Кроме того, есть ли способ предоставить пользователям доступ к sudo, но не разрешать им изменять passwd / group / shadow, чтобы предоставить им доступ к файлам и группам? Мы хотим, чтобы они выполняли административные задачи (установка программного обеспечения, настройка сети / принтеров и т. Д.), Но мы также хотим жестко контролировать, кто имеет доступ к определенным данным.

Хотя я не знаю, как заставить Linux объединять несколько файлов passwd, я хотел бы отметить, что ваша установка является типичным вариантом использования для централизованного управления пользователями с помощью LDAP. К сожалению, пока настройка клиентов Ubuntu для аутентификации LDAP стало довольно легко, настройка сервера OpenLDAP немного раздражает и Я считаю, что в репозиториях отсутствует административное программное обеспечение.

Прагматическое предложение: внутри компании определите диапазон UID для совместного использования в вашей лаборатории и просто напишите небольшой сценарий запуска для клиентов, который синхронизирует часть файлов passwd / shadow / groups с вашей «центральной базой данных пользователей» на сервере ( которые в данном случае могут быть реализованы с помощью простых текстовых файлов).

Что касается части sudo вашего вопроса: / etc / sudoers может содержать информацию о том, какие команды отдельные sudoers могут запускаться с повышенными привилегиями. Однако будет сложно найти надежный способ заблокировать пользователей, но при этом позволить им вообще использовать любой редактор. Цитируется из sudoers справочная страница:

Восклицательный знак ('!') Может использоваться как логический оператор «не» как в псевдониме, так и перед Cmnd. Это позволяет исключить определенные значения. Однако обратите внимание, что использование! в сочетании со встроенным псевдонимом ALL, позволяющим пользователю запускать "все, кроме нескольких" команд, редко работает должным образом

Если вы можете перечислить, какие задачи могут выполнять ваши пользователи, не добавляя «и использовать текстовый редактор для изменения файлов настроек», я не вижу надежного способа сделать это.

Вы можете посмотреть на NIS (или ранее назывался YP).

Или у вас может быть центральная система и периодически составлять список файлов passwd / group / shadow между всеми вашими системами. Этот процесс позволит избежать набора текста и ретуширования в системах и сохранить согласованность этих файлов, если какой-нибудь частный пользователь что-то с ними сделает.

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