Файл /etc/exports содержит настройки сервера NFS для систем Linux. Он определяет, какие файлы и каталоги экспортируются и в каких режимах доступа. Например, файл /etc/exports может содержать следующие записи:
/usr/man crab(rw) horseshoe(rw) (ro) /usr/local (ro) /home/research rodent(rw) crab(rw) horseshoe(rw) jerboas(rw)
Здесь сказано, что:
- /usr/тап доступен для монтирования любому клиенту, но запись в каталог разрешена только узлам crab и horseshoe. Прочим клиентам разрешено только чтение файлов.
- /usr/local может монтироваться любым клиентом, разрешено только чтение файлов.
- /home/research может монтироваться только узлами rodent, crab, horseshoe и jerboas. Этим узлам разрешены чтение и запись.
Параметры каждой из записей файла /etc/exports определяют режимы доступа. Записи подчиняются следующему формату:
каталог [узел (.параметр)].,.
каталог указывает экспортируемый каталог или файл, узел - имя узла или клиента, которому разрешен доступ к экспортированному каталогу, параметр определяет режим доступа для клиента.
В приведенном файле /etc/exports в качестве узла фигурирует имя отдельного клиента. В одном случае имя узла не указано. Если указано имя одного узла, доступ получает отдельный клиент. Если узел не указан, каталог экспортируется для всех клиентов. Подобно Solaris, Linux позволяет использовать домены, сети и сетевые группы, хотя синтаксис немного отличается. Допустимые значения для поля узел:
- Имена отдельных узлов, такие как crab или crab.wrotethebooh.com.
- Маски доменов. Например, маска *wrotethebook.com включает все узлы домена wrotethebook.com.
- Пары вида адрес IP/маска. К примеру, 172.16.12.0/255.255.255.0 включает все узлы, адреса которых начинаются с 172.16.12.
- Сетевые группы, такие как @groupl.
Обратите внимание, что в Linux имена доменов начинаются с символа звездочки (*), а не с точки (.), как в Solaris. Кроме того, символ @ предваряет имя сетевой группы, а не адрес сети, как в Solaris. Параметры, использованные в примере файла /etc/exports:
- ro - Режим только для чтения запрещает клиентам NFS запись в каталог. Попытки записи в такой каталог завершаются неудачно сообщением «Read-only filesystem» (Файловая система доступна только для чтения) или «Permission denied» (Недостаточно полномочий). Если указан параметр го, но отсутствует имя узла клиента, все клиенты получают доступ только для чтения.
- rw - Режим чтения/записи разрешает клиентам чтение и запись в данный ка- талог. Если не указано имя узла, всем клиентам разрешается доступ в режиме чтение/запись. Если указано имя узла, только этот узел получает полномочия чтения/записи.
Итак, отдельные узлы получают доступ в режиме чтения/записи к некоторым из каталогов, однако доступ конкретных пользователей этих узлов регламентируется стандартными для Unix правами уровня пользователя, группы и глобального доступа, вычисляемыми на основе идентификатора пользователя (UID) и группы (GID). NFS считает, что удаленный узел выполнил проверку подлинности пользователей и назначил им корректные идентификаторы UID и GID. Экспортирование файлов дает пользователям системыклиента такой же доступ к этим файлам, как если бы они регистрировались напрямую на сервере. Разумеется, предполагается, что клиент и сервер назначили одинаковые идентификаторы UID и GID каждому из пользователей. Но это далеко не всегда так. Если клиент и сервер назначили один и тот же идентификатор UID определенному пользователю, например идентификатор пользователя Craig равен 501 на обеих системах, тогда обе системы корректно определят пользователя Craig, и он в результате получит доступ к своим файлам. Если же клиентская система назначила пользователю Craig идентификатор UID, равный 501, а сервер назначил тот же UID пользователю Michael, сервер предоставит пользователю Craig доступ к файлам пользователя Michael - так, словно они принадлежат пользователю Craig. В NFS существует ряд механизмов, позволяющих справляться с проблемами, возникающими вследствие такого несовпадения идентификаторов UID и GID.
Первая из очевидных проблем - работа с учетной записью администратора. Маловероятно, что администратор разрешит доступ на сервер пользователям, обладающим root-полномочиями на клиентских системах. По умолчанию NFS блокирует такой доступ параметром root_squash, который выполняет отображение UID и GID пользователя root в соответствующие идентификаторы пользователя nobody. Таким образом, пользователь root с системыклиента может получить только общие полномочия на сервере. Чтобы изменить это поведение, можно воспользоваться установкой no_root_squash, однако no_root_squash делает сервер потенциально уязвимым.
Отображение прочих идентификаторов UID и GID в идентификаторы пользователя nobody достигается при помощи параметров squash_uids, squash_gids и all_squash. all_squash выполняет такое отображение для всех пользователей клиентской системы. squash_uids и squash_gids выполняют отображение конкретных идентификаторов UID и GID. Пример:
/pub (ro,all_squash) /usr/local/pub (squash_uids=0-50, squash_gids=0-50)
Первая запись экспортирует каталог /pub и делает его доступным только для чтения всем клиентам. Все пользователи клиентских систем получают общие полномочия, присущие пользователю nobody, то есть могут читать только те файлы, которые доступны для чтения всем пользователям, а не только владельцу или группе.
Вторая запись экспортирует каталог /usr/local/pub и делает его доступным для чтения/записи (режим по умолчанию) всем клиентам. Параметры squash_uid и squash_gid в данном примере показывают, что для некоторых параметров допустимо указание диапазонов идентификаторов UID и GID. Параметры позволяют указывать отдельные идентификаторы UID или GID, но часто бывает удобно охватить диапазон значений одной командой. В этом примере мы блокируем доступ к каталогу пользователей, идентификаторы UID и GID которых меньше либо равны 50.
Столь низкие значения обычно присваиваются служебным учетным записям. К примеру, на нашей системе Linux UID 10 назначен записи ииср. Попытка записать файл от пользователя ииср приведет к записи файла от имени пользователя nobody. Таким образом, пользователь ииср сможет выполнить запись в каталог /usr/local/pub, только если в этот каталог разрешена запись всем пользователям.
Кроме того, существует возможность связать всех пользователей клиентской системы с конкретным идентификатором пользователя или группы. Задача решается при помощи параметров anonuid и anongid. Они наиболее полезны, если доступ к клиентской системе имеет только один пользователь и этому пользователю не назначаются идентификаторы. Например, такова ситуация с персональным компьютером под управлением Microsoft Windows, на котором работает NFS. У персонального компьютера обычно только один пользователь, и к нему неприменимы понятия идентификаторов UID и GID. Чтобы связать пользователя персонального компьютера с корректными идентификаторами пользователя и группы, создайте подобную строку в файле /etc/exports:
/home/alana giant(all_squash,anonuid=1001lanongid=1001)
В данном примере имя узла компьютера Аланы - giant. Запись разрешает клиенту доступ к каталогу /home/alana в режиме чтения/записи. Параметр all_squash преобразует все запросы от клиента, подставляя конкретный идентификатор UID, однако на этот раз вместо идентификаторов пользователя nobody подставляются идентификаторы, указанные в параметрах anonuid и anongid. Разумеется, чтобы прием сработал, сочетанию 1001:1001 должна соответствовать пара идентификаторов UID/GID, назначенная пользователю alana в файле /etc/passwd.
Единичного отображения достаточно для персонального компьютера, однако его явно не хватит для полноценной работы с Unix-клиентом. Клиенты Unix назначают своим пользователям идентификаторы UID и GID. Если тем же пользователям на сервере NFS назначены другие идентификаторы, начинаются сложности.
Воспользуйтесь параметром map_static, чтобы указать файл, в котором хранятся отображения идентификаторов UID и GID для конкретного клиента. Пример:
/export/oscon oscon(map_static=/etc/nfs/oscon.map)
Данная запись экспортирует каталог /export/oscon для клиента oscon в режиме чтения/записи. Параметр map_static указывает, что в файле /etc/nfs/ oscon.map на сервере хранятся отображения идентификаторов, позволяющие пользователям узла oscon корректно работать с сервером. Файл oscon.map может содержать записи следующего характера:
# UID/GID mapping for client oscon # remote local comment uid 0-50 - «squash these gid 0-50 - «squash these uid 100-200 1000 «map 100-200 to 1000-1100 gid 100-200 1000 «map 100-200 to 1000-1100 uid 501 2001 «map individual user gid 501 2001 «map individual user
Первые две строки преобразуют идентификаторы UID и GID от 0 до 50 в идентификаторы пользователя nobody. Следующие две строки преобразуют все идентификаторы клиентов из диапазона от 100 до 200 в соответствующие числа из диапазона от 1000 до 1100 на сервере. Иначе говоря, пользователь с идентификатором 105 на клиенте получает идентификатор 1005 на сервере. Записи такого рода встречаются чаще всего. В большинстве систем присвоение существующих идентификаторов UID и GID происходило последовательно. Зачастую различные системы назначают пользователям идентификаторы, начиная с 101 последовательно, но не согласованно. Данная запись выполняет отображение для пользователей узла oscon, назначая им идентификаторы начиная с 1000. В другом файле может выполняться отображение идентификаторов с 100 по 200 уже для другого клиента - в идентификаторы сервера, начинающиеся с 2000. В третьем файле идентификаторы третьего клиента могут получить уже порог 3000. Таким образом, существует возможность согласовывать на сервере идентификаторы в случаях, когда никакой согласованности не существует. Последние две строки выполняют отображение идентификаторов UID и GID отдельного пользователя. Такие записи требуются реже, но все же встречаются время от времени.