Отображение пользовательских имен

На компьютере под управлением Linux, работающем независимо от других машин, за отображение пользовательских имен в числовые идентификаторы (UID) отвечает файл /etc/passwd. Аналогично, информация о соответствии имен групп и их идентификаторов (GID) хранится в файле /etc/group. В системе NFS существуют как минимум два независимых файла /etc/passwd: один — на сервере и по одному — на каждом клиенте. При этом может возникнуть проблема, связанная с тем, что одному и тому же пользователю на сервере и на клиентской машине будут соответствовать различные UID. Эта проблема может быть решена различными способами.

При рассмотрении данного вопроса предполагается, что пользователь имеет учетную запись и на клиентском компьютере, и на сервере. Если сервер используется только в качестве файлового сервера и содержащаяся на нем информация доступна только для чтения, учетная запись пользователя на нем может отсутствовать. Такая же конфигурация может быть реализована на некоторых серверах, допускающих чтение и запись. При настройке сервера, который допускает чтение и запись и обслуживает несколько пользователей, вопрос синхронизации числовых идентификаторов становится очень важным. Если на сервере NFS хранятся файлы, принадлежащие некоторому пользователю, целесообразно создать на сервере учетную запись данного пользователя, даже если он никогда не будет регистрироваться на этой машине. Если же пользователь не является владельцем ни одного из файлов, хранящихся на сервере, отображать пользовательское имя не требуется. Согласование идентификаторов пользователей на клиентском компьютере и на сервере.

Самым простым решением описанной выше проблемы отображения пользовательских имен является синхронизация UID и GID на клиентской машине и на сервере. Например, если некоторому пользователю на сервере соответствует идентификатор 504, необходимо принять меры к тому, чтобы и на клиентском компьютере его UID был также равен 504. Аналогичным образом должны быть синхронизированы GID. Если сеть насчитывает большое число компьютеров, синхронизация UID и GID займет очень много времени. Однако в небольшой сети, при условии, что число пользователей в ней невелико, действия по синхронизации могут быть выполнены относительно просто. Привести в соответствие существующие пользовательские идентификаторы можно с помощью утилиты usermod. Например, для того, чтобы изменить UID пользователя abrown с 507 на 504, надо вызвать следующую команду:

# usermodu 504 abrown.

При выполнении этой команды будет изменена запись в файле /etc/passwd и скорректированы данные о владельце файлов, расположенных в рабочем каталоге данного пользователя. (Информацию о принадлежности файлов, которые находятся за пределами рабочего каталога, следует ввести вручную.) Для завершения этой команды потребуется некоторое время. Если вы прервете ее выполнение, вам придется самостоятельно задавать нового владельца некоторых файлов, содержащихся в рабочем каталоге пользователя.

Команда groupmod аналогичным образом изменяет информацию о группе. В отличие от команды usermod, новый идентификатор группы задается с помощью опциид. Например, чтобы задать GID группы proj ect3 равным 127, надо выполнить следующую команду:

# groupmodg 127 project3.

ВНИМАНИЕ Не пытайтесь изменить UID или GID в то время, когда пользователь, идентификатор которого должен быть скорректирован или члены группы зарегистрированы в системе. Это приведет к тому, что пользователь не сможет сохранить результаты своей работы, прочитать файл, запустить программу и выполнить другие подобные действия. Если вы внесли такие изменения непреднамеренно, постарайтесь отменить их либо предложите пользователю завершить сеанс работы и зарегистрироваться повторно. Если при этом пользователю необходимо сохранить данные, их можно записать в один из общедоступных каталогов, например в/trap.

Говоря о данном способе синхронизации идентификаторов, важно заметить, что имена пользователя на клиентской машине и на сервере не обязательно должны совпадать. Например, один и тот же пользователь может иметь имя abrown на сервере и имя alyson — на клиентском компьютере. Когда этот пользователь, работая в клиентской системе, обращается к серверу, считается, что файлы на сервере принадлежат пользователю alyson. Если тот же пользователь зарегистрируется на сервере NFS, система сообщит, что владельцем файлов является abrown. Первоначально такая особенность затрудняет администрирование системы, но в некоторых ситуациях она может оказаться полезной. Обеспечить синхронизацию UID и GID можно, используя отдельный сервер для аутентификации пользователей как на клиентских компьютерах, так и на сервере NFS. В этом случае пользователь получит один и тот же UID, независимо от компьютера, на котором он зарегистрируется, а конкретной группе будет соответствовать единственный GID. В качестве такого средства аутентификации можно использовать систему Kerberos, которая была рассмотрена в главе 6. Кроме того, реализация NFS для Linux включает поддержку аутентификации NIS; для этой цели используется опция map_nis. Если вы включите эту опцию в файл /etc/exports для некоторого клиента, сервер NFS предоставит серверу NIS выполнить отображение пользовательского имени. Средства синхронизации идентификаторов пользователей, выполняемые на стороне сервера. Предположим, что вы занимаетесь администрированием сети, состоящей из двух компьютеров. На каждом узле этой сети существуют учетные записи для пользователей, перечисленных в табл. 1. В данном примере компьютер gingko выполняет функции сервера, а компьютер larch выступает в роли клиента. Только у одного из пользователей (j ames) идентификаторы на обоих компьютерах совпадают. Чтобы пользователь j ames мог обращаться к своим собственным файлам, никакие специальные меры не требуются. Работая на компьютере larch, alyson обнаружит, что его файлы, хранящиеся на gingko, принадлежат пользователю, идентифицировать которого невозможно (UID, равный 500, на компьютере larch отсутствует). Что касается остальных двух пользователей, Jennie и samuel, система сообщит, что каждый из них является владельцем файлов, принадлежащих на самом деле другому. Один из способов решения проблемы синхронизации пользовательских идентификаторов состоит в следующем. На сервере NFS создается файл соответствия идентификаторов, содержащий информацию, подобную приведенной в табл. 1. О наличии этого файла сервер оповещается посредством опции map_static; в качестве значения опции Таблица 1. Идентификаторы пользователей на двух компьютерах.

задается имя файла соответствия идентификаторов. В файл /etc/exports включается запись, которая может выглядеть следующим образом:

/home larch (rw, map_static=/etc/nfs/larch-map).

Эта запись сообщает системе о том, что, предоставляя каталог /home пользователю larch, надо использовать файл соответствия идентификаторов с именем /etc/nfs/ larch-map. Поскольку опция map_static входит в состав списка опций для конкретного клиента, вы можете назначать разным клиентам различные файлы соответствия. Пример содержимого файла larch-map показан в листинге 2. Строки, в начале которых находится символ #, содержат комментарии. Строки, начинающиеся с uid, представляют информацию о соответствии пользовательских идентификаторов, а строки, в начале которых расположено ключевое слово gid, содержат сведения о соответствии идентификаторов групп. Первое из числовых значений (или диапазон значений) в строке представляет идентификатор на клиентской машине. Второе числовое значение соответствует идентификатору, в который должен отображаться UID или GID, полученный на удаленном компьютере. Например, из листинга 2 видно, что UID 504 на клиентском компьютере отображается в UID 500 на сервере. Если вместо идентификатора на сервере указан символ -, обращение данного пользователя или члена группы к серверу NFS запрещен. Такое обращение интерпретируется как попытка доступа анонимного пользователя.

Листинг 2. Пример содержимого файла соответствия идентификаторов.

# Отображение идентификаторе.

# удаленный локальный.

uid 0−99 ;

uid 504 500.

uid 501 501.

uid 503 502.

uid 502 503.

gid 0−99 ;

gid 100−102 100.

;ля клиента larch.

# доступ запрещен.

# доступ запрещен В файле соответствия необходимо задать идентификаторы всех пользователей. Например, в листинге 8.2 указан UID 501, который отображается в тот же идентификатор на сервере. Отсутствующий UID приведет к некорректному отображению, что, в свою очередь, станет источником проблем. В листинге 8.2 явным образом указано, что попытки обращения с системных UID (с номерами меньше 100) должны отвергаться. Аналогичное правило задано для идентификаторов групп 0−99. GID 100−102 отображаются в GUID 100. Несмотря на то что вы можете отобразить диапазон клиентских идентификаторов в единственный идентификатор на сервере, обратное действие не имеет смысла. При попытке пользователя с определенным UID на стороне клиента создать файл сервер не сможет выбрать локальный идентификатор.

Как и в случае, когда синхронизация идентификаторов на клиентской машине и сервере производится вручную, имена пользователей на клиентском компьютере и на сервере могут различаться. В файле соответствия содержится исключительно информация об идентификаторах пользователей и групп; сведения об именах отсутствуют. Несмотря на то что подобная ситуация не мешает нормальной работе, желательно согласовать пользовательские имена на клиентских компьютерах и на сервере.

Средства синхронизации идентификаторов пользователей, выполняемые на стороне клиента Решить проблему синхронизации пользовательских идентификаторов можно, задавая на стороне сервера опцию map_daemon. Эта опция позволяет использовать на стороне клиента специальный демон, который называется ugidd или rpc.ugidd. Однако при работе с таким демоном могут возникать проблемы. Во-первых, программа ugidd поставляется не со всеми системами. Из дистрибутивных пакетов, которые обсуждались в данной книге, она входит только в состав Debian. Во-вторых, демон ugidd приходится устанавливать на всех клиентах, а это занимает много времени. В-третьих, чтобы программа не могла быть использована для несанкционированного доступа, необходимо запретить обращения к ней (это можно сделать, задавав требуемую конфигурацию в файле /etc/hosts.allow). И, наконец, что особенно важно, данная программа слишком сложна и в некоторых случаях она вовсе не работает либо отображает всех пользователей в пользователя nobody.