Так как клиенты протокола NFSv2 принимают некоторые решения на доступ локально, они будут неправильно гарантировать доступ на чтение файла и содержимого каталога, кэшированных на клиенте, для пользователей, которые входят в группу-владелец в двух случаях. Первый, если разрешения класса групп включают право на чтение, но группа-владелец такого права не имеет. Второй, если группа-владелец имеет разрешение на чтение, но существует ACE именного пользователя для данного пользователя, в которой отсутствует разрешение на чтение. Обе ситуации довольно редки. Существуют решения, которые уменьшают разрешения на стороне сервера так, чтобы клиенты видели только необходимый им реальный набор разрешений [10,7]. Для пользователей, не входящих в группу-владелец, такие аномалии не возникают.

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

Версия 3 протокола NFS определяет новый удаленный вызов процедур (RPC) ACCESS для передачи полномочий на принятие решений относительно прав доступа на сервер. Этот RPC схож с системным вызовом доступа. Ожидается, что клиенты NFSv3 будут использовать этот RPC для определения кому должен быть предоставлен доступ к кэшированному содержимому.

Протокол NFSv3, к несчастью, не определяет механизма передачи ACL. Как следствие, различные изготовители реализовали правильные расширения протокола, которые не совместимы друг с другом. Реализованное в Solaris расширение протокола NFS ACL поддерживает только ACL. Более общая реализация протокола в Irix поддерживает EAs и манипулирует ACL как специальными EAs.

Протокол NFSv4 определяет структуру и семантику своих собственных ACL наряду с RPC для передачи их между клиентом и сервером. ACL NFSv4 похожи на ACL Microsoft Windows [14]. К несчастью, дизайнеры NFSv4 в основном проигнорировали существование POSIX ACL, и, таким образом, ACL NFSv4 не совместимы с POSIX ACL. Мариус Амодт Эриксен (Marius Aamodt Eriksen) описывает одностороннее соответствие между POSIX ACL и ACL NFSv4 [6], но это соответствие непрактично. Одним из центральных понятий в POSIX ACL, которое необходимо для гарантии совместимости с приложениями POSIX.1, является запись-маска. Модель ACL NFSv4 может быть расширена понятием маски. И хотя это позволило бы сильно улучшить взаимодействие с POSIX ACL, предложения расширить спецификацию NFSv4 до сих пор отклонялись.

Частичная поддержка NFSv3 была добавлена в ядра Linux версии 2.2. ACCESS RPC был добавлен в NFS демон ядра в версии 2.2.18, но клиенты NFS корректно используют ACCESS RPC только в ядрах версии 2.5. Патч для более старых версий ядра существует с версии 2.4.19.

Так как ACCESS RPC может приводить к значительным издержкам в сети даже для файловых систем, о которых известно, что в них нет ACL, клиенты Linux NFSv3 могут монтировать файловые системы с опцией noacl. В этом случае клиент не будет использовать ни ACCESS RPC, ни GETACL RPC, ни SETACL RPC. Для того, чтобы гарантировать, что никакие ACL не будут установлены на сервере, файловые системы Ext2, Ext3, JFS и ReiserFS могут быть смонтированными на сервере без поддержки ACL, если опустить опцию монтирования acl.

С 3 марта 2003 года реализация протокола NFS ACL компании Sun для Linux доступна на сайте http://acl.bestbits.at/. Был выбран протокол NFS ACL, так как он достаточно прост и он достаточно хорошо поддерживает ACL драфта 17 POSIX 1003.1e. В Solaris ACL основаны на более ранних драфтах POSIX 1003.1e, и поэтому существуют различия в способах обработки маски для ACL только с четырьмя записями. Это довольно частный случай и возникает он довольно редко, так что семантические отличия могут быть не настолько очевидными.

3.5 Samba и ACL

Microsoft Windows поддерживает ACL в своей файловой системе NTFS и в своем протоколе CIFS [20], который формально известен как протокол SMB. CIFS используется для предоставления доступа к файловым сервисам и сервису печати по сети. Samba является Open Source реализацией CIFS. Samba используется для предоставления доступа к файловым сервисам и сервису печати для пользователей Windows в сети. Samba позволяет манипулировать POSIX ACL из Windows. Эта особенность добавляет новый аспект во взаимном общении UNIX и Windows.

Модель ACL в Windows отличается от модели POSIX ACL по ряду причин, поэтому оказывается невозможным предоставление полной интеграции. Наиболее значительное различие между этими двумя моделями состоит в следующем:

ACL в Windows поддерживают около десяти различных разрешений для каждой записи в ACL, включая такие как “дописать”, “удалить”, “изменить разрешения”, “присвоить владение”, “изменить владельца”. Текущие реализации POSIX ACL поддерживают только разрешения на чтение, запись и выполнение.

В алгоритме проверки разрешений POSIX гарантируется, что процесс получит доступ согласно наиболее значащей ACE, определяющей разрешения. Таким образом, более детальные разрешения конструируются добавлением более близко подходящих ACE по необходимости. В модели Windows ACL имеют накопленный характер, то есть разрешения которые будут гарантированы в любом случае могут быть запрещены только запрещающими ACE.

POSIX ACL не поддерживают запрещающих ACE. Запретить доступ для пользователя можно созданием специального ACE именного пользователя, в котором будут отсутствовать разрешения.

Иерархическая модель ACL Windows была похожа на модель POSIX ACL. Начиная с Windows 2000 Microsoft использует динамическую иерархическую модель, которая предоставляет разрешения распространяясь вниз по иерархии каталогов, когда изменяются разрешения корневого (родительского) каталога. POSIX ACL наследуются только в момент создания файла.

В модели POSIX ACL доступа и ACL по-умолчанию являются ортогональными понятиями. В модели ACL Windows несколько различных флагов в каждой ACE управляют тем, как и когда запись наследуется контейнерами и объектами, не являющимися контейнерами.

ACL в Windows имеют различные концепции определения разрешений для владельца и группы-владельца. Понятие группы-владельца было введено только с Windows 2000. Это приводит к различным результатам смены владельца.

POSIX ACL имеют записи для владельца и группы-владельца как в ACL доступа, так и в ACL по-умолчанию. В момент проверки прав доступа к объекту эти записи ассоциируются с текущим владельцем и группой-владельцем этого объекта. ACL в Windows поддерживают две псевдогруппы: владелец-создатель и группа-создатель, которые служат похожим целям наследования разрешений, но эти псевдогруппы не действительны для записей, определяющих доступ. Когда объект наследует разрешения, эти абстрактные записи конвертируются в записи для конкретного пользователя и группы.