Общая информация об NFS
Категория: Сетевая файловая система | Автор: admin | 9-05-2010, 14:35 | Просмотров: 3855

Сетевая файловая система состоит из ряда компонентов, включая протокол и сервер монтирования, демоны, координирующие работу базового файлового сервиса, а также несколько диагностических утилит. Части клиентского и серверного программного обеспечения NFS находятся непосредственно в ядре. К счастью, они не требуют конфигурирования и преимущественно "прозрачны" с точки зрения администрирования.

 

Версии протокола NFS

 

Протокол NFS отличается удивительной стабильностью. Первый открытый выпуск NFS имел версию 2. В начале 90-х гг. в протокол были внесены изменения, которые привели к появлению версии 3. Ее характеризовали повышенная производительность и улучшенная поддержка больших файлов.

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

В версии 3 данное узкое место было устранено за счет схемы согласования, которая позволяет выполнять операции записи асинхронно. Был улучшен также ряд других параметров протокола, связанных с производительностью, вследствие чего NFS 3 стала работать гораздо быстрее, чем NFS 2.

Сервер версии 3 всегда может взаимодействовать с сервером версии 2. Просто он при этом переключается на использование более старого протокола.

 

Выбор транспортного протокола

 

В основе NFS лежит протокол RFC (Remote Procedure Call — удаленный вызов процедур) компании Sun, который определяет системно-независимый способ взаимодействия процессов по сети. Положительным побочным эффектом этой архитектуры является возможность выбора транспортного протокола — TCP или UDP.

Изначально в NFS применялся протокол UDP, поскольку он обеспечивал наилучшую производительность в локальных сетях 80-х гг. И хотя программное обеспечение NFS само выполняет сборку пакетов и осуществляет контроль ошибок, но ни в UDP, ни в NFS не реализованы алгоритмы контроля перегрузки, которые необходимы для достижения нормальной производительности в крупной ІР-сети.

С целью решения этих проблем в большинстве систем было разрешено использовать в качестве транспортного протокола для NFS не UDP, a TCP. Первоначально данная возможность предназначалась для обеспечения работы NFS через маршрутизаторы и в сети Internet. Но в настоящее время большинство специалистов рассматривает TCP и как оптимальное средство для управления локальным трафиком. В конце концов, по мере удешевления памяти и роста производительности центральных процессоров первоначальные доводы в пользу UDP становятся все менее актуальными.

Серверы, поддерживающие протокол TCP, как правило, принимают запросы на установление соединений от обоих транспортных протоколов, поэтому выбор между TCP и UDP делает клиент. Большинство клиентов по умолчанию работают с UDP; Solaris к их числу не относится.

Поддержка TCP официально появилась в спецификации протокола NFS версии 3, но существуют реализации версии 2, где такая поддержка тоже имеется (например, в Red Hat). В то же время есть и реализации версии 3, где поддержка TCP отсутствует (в частности, в HP-UX).

Все данные о поддержке протокола TCP и NFS версии 3 в наших тестовых системах сведены в табл. 17.1. В колонке "По умолчанию" указано, какому протоколу отдает предпочтение клиентская часть системы.

 

Таблица 17.1. Поддержка расширенных возможностей NFS в операционных системах

Система

NFSv3?

TCP?

По умолчанию

Solaris

Да

Да

TCP

HP-UX

Да

Нет

UDP

Red Hat

Нет

Да1

UDP

FreeBSD

Да

Да

UDP

1   Протокол TCP поддерживается только на стороне клиента.

 

WebNFS

 

В 1996 г. компания Sun предприняла попытку внедрить NFS в глобальную сеть, предложив собственную оригинальную систему WebNFS. Будучи надмножеством стандартного протокола NFS версии 3, WebNFS устраняет (точнее, делает необязательными) некоторые вступительные транзакции, через которые должен пройти традиционный клиент NFS, прежде чем он получит доступ к файловой системе. Этот механизм предназначен не для замены NFS, а для поддержки апплетов, выполняющихся в среде Web-броузеров. Следовательно, для организаций, не занимающихся написанием таких апплетов, система WebNFS не представляет особого интереса.

Все наши тестовые операционные системы (кроме HP-UX) обеспечивают серверную поддержку протокола WebNFS. Дополнительную информацию можно получить по адресу www.sun.com/webnfs.

 

Блокировка файлов

 

Блокировка файлов (реализуемая системными вызовами flock и/или lockf) в течение долгого времени являлась "больным" вопросом для UNIX-систем. В локальных файловых системах этот механизм был реализован далеко не идеально. Что касается NFS, то положение все еще неустойчиво. Серверы NFS не поддерживают понятие сеанса: они не знают о том, какие компьютеры работают с конкретным файлом. Но эта информация необходима для использования блокировок. Как быть?

Традиционное решение заключается в реализации механизма блокировок отдельно от NFS. В большинстве систем этой цели служат два демона: lockd и statd. К сожалению, реализация такого подхода затруднена по ряду причин, поэтому блокировка файлов в NFS часто организована неоптимальным образом.

 

Дисковые квоты

 

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

 

Глобальные идентификаторы пользователей и групп

 

В UNIX пользователи и группы пользователей идентифицируются по номерам. Если пользователь компьютера X имеет файлы на компьютере Y, то желательно, чтобы его идентификатор был одинаковым в обеих системах, иначе могут возникнуть серьезные проблемы с безопасностью или конфиденциальностью.

 

В некоторые серверы NFS были внедрены средства преобразования удаленных идентификаторов в локальные, но эта возможность не является частью официального протокола NFS и не может считаться надежной при работе с несколькими операционными системами. Мы рекомендуем обращаться с идентификаторами старым, но надежным способом: следует сделать так, чтобы на всех компьютерах, где происходит совместная работа с файлами за пользователями и группами были закреплены одни и те же номера. Чтобы избавить администратора от головной боли, добейтесь уникальности идентификаторов в пределах всей организации.

Серверы NFS не требуют регистрации удаленных пользователей в системе. Пользователь может даже не иметь записи в файле /etc/passwd, если только на сервере не установлена какая-нибудь необычная опция, например map_nis в Red Hat.

 

Учетные записи root и nobody

 

В общем случае пользователи должны иметь одинаковые привилегии в любой системе, к которой они получают доступ. Однако традиционно ограничиваются возможности неконтролируемого применения прав суперпользователя в файловых системах, смонтированных посредством NFS. По умолчанию сервер NFS перехватывает входящие запросы, посылаемые от имени пользователя с идентификатором 0, и "делает вид", будто они поступают от другого пользователя. Таким образом, учетная запись root не отменяется, но уравнивается в правах с обычными учетными записями.

В большинстве систем специально определена фиктивная учетная запись nobody, чтобы под нее "маскировался" пользователь root, работающий на сервере NFS. Ее идентификатор может быть разным в зависимости от системы и в принципе не играет особой роли; чаще всего это -2 или 65534. Важно то, что этот идентификатор не пересекается ни с одним из идентификаторов реальных пользователей. В Solaris и HP-UX доступ в систему будет вообще запрещен, если назначить учетной записи root идентификатор -1.

Все эти предосторожности преследуют благородную цель, однако конечный результат далек от идеала. Будучи клиентом NFS, пользователь root может с помощью команды su "принять облик" любого пользователя, так что наши файлы никогда не бывают полностью защищены. Системные учетные записи, такие как bin и sys, не подвергаются смене идентификатора поэтому принадлежащие им файлы (а это большой процент системных файлов) открыты для нападений. Единственный действенный эффект от смены идентификаторов заключается в том, что предотвращается доступ к файлам, которые принадлежат пользователю root и недоступны для чтения или записи остальным пользователям.

 

Секретные ключи и монтирование без учета состояния

 

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

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

Если у клиента есть секретный ключ, он может с помощью протокола RPC посылать файловой системе запросы, например на создание файла или чтение блока данных. Поскольку в NFS нет понятия сеанса, то серверу все равно, какие запросы клиент делал (или не делал) ранее. В частности, прежде чем удалять собственную копию данных, подлежащих записи, клиент сам должен убедиться что сервер подтвердил запрос на запись.

 

Соглашения об именах совместно используемых файловых систем

 

Управлять сетевой файловой системой становится проще, если придерживаться стандартной схемы именования. Полезны такие имена, которые содержат имя сервера (например, /anchor/tools — файловая система, расположенная на машине anchor), потому что они позволяют переводить объявления вида "машина anchor будет всю субботу отключена в связи с модификацией" в "я не смогу поработать над файлом /anchor/tools/TeX в субботу, чтобы закончить диссертацию, поэтому лучше отправлюсь на лыжную прогулку".

К сожалению, эта схема требует, чтобы каталог /anchor существовал в корневых каталогах всех клиентских компьютеров. Если клиент получает доступ к файловым системам, расположенным на нескольких машинах, его корневой каталог может оказаться захламленным. Рассмотрите возможность углубления иерархии: например, используйте каталоги /home/anchor, /home/rastadon и т.д. Мы советуем прибегнуть к помощи демонов автоматического монтирования, описание которых начинается в параграфе 17.6.

 

Безопасность и NFS

 

Сетевая файловая система предоставляет удобный способ доступа к файлам по сети и потому является серьезным источником угроз для безопасности. Она подобна тренажеру, на котором можно проверять любые бреши, существующие или когда-либо существовавшие в UNIX.

Изначально в протоколе NFS не были предусмотрены никакие средства защиты. Позднее лежащий в его основе протокол RPC подвергся модификации и появилась возможность использовать подключаемые модули аутентификации. Однако новая спецификация так и не предложила конкретного механизма защиты.

Тогда на арену вышли два конкурента: компания Sun, представившая собственную технологию на основе систем шифрования с открытым ключом, проигнорированную другими поставщиками, и система Kerberos, расширившая свои стандартные средства аутентификации на RPC. Оба решения позволяли убедиться, что удаленный пользователь действительно тот, за кого себя выдает. Но ни в одном из случаев данные, передаваемые по сети, не подвергались шифрованию, поэтому пользователи по-прежнему находились во власти хакеров, пользовавшихся анализаторами пакетов.

 

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

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

При наличии в организации брандмауэра блокируйте доступ к TCP- и UDP-портам 2049, которые используются протоколом NFS. Кроме того, необходимо блокировать доступ к демону portmap системы Sun RPC, который обычно прослушивает TCP- и UDP-порты 111. Несмотря на все эти предосторожности, не стоит также забывать правило, согласно которому файловые системы NFS не должны экспортироваться на нелокальные машины (WebNFS не в счет).



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page