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

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

Запись-маска в POSIX ACL не имеет своего аналога в ACL Windows. Если разрешения в POSIX ACL неэффективны из-за маскировки, то эти разрешения убираются из ACL в момент передачи через CIFS.

Так как ACL в Windows поддерживают только псевдогруппы владельца-создателя и группы-создателя для наследования разрешений, то этим псевдогруппам будут соответствовать владелец и группа-владелец в ACL по-умолчанию. Для ACL доступа эти записи соответствуют именованным записям для текущего владельца и текущей группы-владельца (например, запись “u::rw” в POSIX ACL для файла, владельцем которого является Joe, расценивается как “u:joe:rw”).

Если ACL доступа содержит именованные ACE для владельца и группы-владельца (например, если один из файлов, владельцем которого является Joe, имеет запись “u:joe:…”), разрешения, определенные в таких записях, не будут эффективными до тех пор, пока не сменится владелец, таким образом, такие именованные ACE игнорируются. Если Samba создает ACL, содержащий записи для владельца-создателя и группы-владельца, то этим записям предшествуют именованные записи для текущих владельца и группы-владельца соответственно.

Записи в POSIX ACL доступа и ACL по-умолчанию, определяющие те же разрешения, что и записи ACL Windows, маркируются как определяющие доступ и правила наследования разрешений.

3.6 Резервные копии и восстановление

Важным и наиболее легко рассматриваемым аспектом представления таких новых особенностей, как EAs и ACL, является создание резервных копий. Стандартные инструменты, такие как GNU tar и GNU cpio, не включают поддержки EA и ACL. Форматы архивов ustar и cpio, на которых основаны эти утилиты, не разрешают конкретные расширения, но до сих пор не было определено никакого стандарта хранения EAs или ACL.

Текущая версия POSIX.1 [11] определяет новую утилиту pax, которая отвечает за взаимообмен перемещаемыми архивами. В добавление к своему новому формату архивов утилита pax поддерживает также форматы архивов ustar и cpio. Этот новый формат основан на ustar и, соответственно, в большой степени с ним совместим. Pax предоставляет механизм под названием расширенные заголовки. Расширенные заголовки, состоящие из списка атрибутов, очень похожи на EAs. Они используются для хранения вещей, которые не могут быть представлены в заголовках ustar, как например второе под-разрешение файловых временных штампов или размеры файлов в 8 Гб и более.

Формат архивов pax отлично подходит для хранения EAs и ACL. Так как ни EAs, ни ACL не являются частью стандарта POSIX, то, соответственно, не определено специфического формата для использования EAs и ACL в расширенных заголовках. Спецификация оставляет место для специфических атрибутов производителя, помеченных его именем, так что даже если не может быть достигнуто никакого соглашения относительно использования форматов EAs и ACL, специфические расширения производителя могут быть по крайней мере достаточными и реализации могут поддерживать более одного расширения.

Выгода в использовании формата pax состоит в том, что они могут быть распакованы с использованием реализаций tar. Для tar расширенные заголовки выглядят как файлы неизвестного формата. Информация, которая хранилась в расширенных заголовках будет потеряна, но все файлы и каталоги будут распакованы правильно. Это, правда, не будет работать для архивов pax, которые содержат файлы размером 8 Гб и более; это максимальный размер файлов в tar архивах.

Существуют следующие решения для создания резервных копий (с последующим восстановлением) EAs и ACL:

Реализация pax и tar Жогра Шиллинга (Jörg Schilling), названная star, включает поддержку POSIX.1e ACL и некоторых других. Полученные архивы являются переносимыми среди систем, которые реализуют различные версии POSIX ACL, включая FreeBSD, Irix, Compaq/HP Tru64, Linux, Solaris. Существует также патч, которые реализует поддержку Linux EA в star. Star доступен по адресу ftp://ftp.berlios.de/pub/star/.

Для файловой системы XFS могут использоваться утилиты xfsdump (создание резервных копий) и xfsrestore (восстановление из резервных копий). Такой подход не рекомендуется в силу того, что формат резервных копий будет специфичен для конкретной файловой системы.

Наконец, утилиты getfattr и getfacl могут сохранять ACL и EAs в текстовые файлы. Обратное преобразование производят утилиты setfattr и setfacl. Этот подход оправдан для восстановления целостных (единых) резервных копий, но он довольно непрактичен для восстановления отдельных файлов.

3.7 Поддержка ACL на уровне приложений

В настоящее время наиболее основными инструментами, необходимыми для оперирования в операционной системе с EAs и ACL, то есть где основные файловые утилиты (ls, cp, и mv) поддерживают EA и ACL, являются утилиты управления EAs и ACL из командной строки, различные реализации системы резервного копирования, которая использует эти особенности. В настоящее время все еще существует много приложений, в которых не хватает такой поддержки. Хотя для большинства из них это неприемлемо, для некоторых классов приложений это приводит к различного рода проблемам. В этот класс входят файловые менеджеры, редакторы и инструменты синхронизации файловых систем.

Файловые менеджеры обычно могут копировать и перемещать файлы и разрешать изменение разрешений доступа. Ядра UNIX не имеют функций копирования или перемещения файлов между границами файловых систем. Поэтому эти операции реализуются чтением содержимого файла-источника с последующим копированием этих данных в файл-назначение. По отдельным командам, передаваемым ядру, оно не может определить, производится ли сейчас копирование (или перемещение) файла или что-либо другое, то есть не может следить за соответствие этих операций правилам EAs и ACL. Это означает, что приложения должны сами по необходимости заботиться о соответствии всех выполняемых действий правилам EAs и ACL.

Во многих утилитах существуют проблемы, связанные с копированием файлов. Существует два способа безопасного редактирования файла. Первый заключается в создании копии оригинального файла с последующей модификацией оригинала. Вторая заключается в переименовании оригинального файла и создании нового файла, который включает изменения оригинала. Второй способ эквивалентен копированию файлов в случае существования EAs и ACL. Существуют также дополнительные последствия для файлов, являющихся символическими ссылками, и файлов со счетчиком ссылок более единицы. Emacs и vi, наиболее популярные редакторы в UNIX-подобных системах, могут быть сконфигурированы для использования любого из этих методов.