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

Необходимо также отметить, что временные задержки в случае ACL сильно менялись в зависимости от поддерживаемых файловых систем. Эти различия больше проявляются при маленьких нагрузках на систему ввода-вывода и становятся менее очевидными при больших загрузках системы ввода-вывода. Для ACL реализации Ext2 и Ext3 имеют небольшие временные задержки. Расходы на EAs в ReiserFS достаточно высоки. Эту ситуацию можно улучшить, если реализовать механизм разделения EAs. Для XFS имеет большое значение увеличения размера inode с тем, чтобы ACL уменьшался прямо в нем.

3.2.6 Реализации ACL

Интересным с точки зрения реализации является то, каким образом ACL передается между пользовательским пространством и ядром, и внутри ядра между виртуальной файловой системой (VFS) и низкоуровневым слоем файловой системы. FreeBSD, Solaris, Irix и HP-UX имеют отдельные системные вызовы ACL [21,9,23,17].

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

Рациональность в использовании отдельных системных вызовов ACL в FreeBSD обусловлена тем, что некоторые файловые системы поддерживают EAs, но не поддерживают ACL, а некоторые файловые системы поддерживают ACL, но не поддерживают EAs, и, следовательно, EAs воспринимаются как двоичные данные в чистом виде. EAs и ACL становятся родственными только внутри файловой системы [24,26].

Рациональность реализации Linux заключается в предоставлении доступа ко всем метаданным объекта файловой системы через единый интерфейс. Имена атрибутов “system.posix_acl_access” и “system.posix_acl_default” используются для ACL доступа и ACL по-умолчанию файла соответственно. Значения атрибута имеют канонический и архитектурно-независимый двоичный формат.

Хотя возможна манипуляция ACL напрямую как EAs, на уровне приложения это не всегда так: так как системные вызовы EA специфичны для Linux, такие приложения не будут переносимыми (независимыми от ОС). Другие операционные системы поддерживают похожие механизмы EA, но с различными интерфейсами системных вызовов. Приложения, которые стремятся к использованию POSIX.1 ACL в переносимом смысле, должны использовать библиотеку libacl, которая реализует ACL-специфические функции соответственно драфту 17 POSIX.1e.

Доступ к ACL доступа объекта файловой системы осуществляется перед каждым решением на доступ, которое включает этот объект. Проверка доступа осуществляется на всем пути от исходного пространства пользователя до файла. Для того, чтобы избежать частого просмотра атрибутов ACL и конвертирования из архитектурно-независимого представления атрибутов в архитектурно-специфическое, реализации Ext2, Ext3, JFS и ReiserFS используют кэширующие механизмы, которые используют либо кэш страницы, либо буферный кэш, либо их вместе. XFS не использует этот дополнительный уровень кэширования.

Большинство UNIX-подобных систем, поддерживающих ACL, ограничивают максимальное число возможных ACE каким то числом. Таблица 7 показывает эти ограничения для Linux.

Таблица 7: Максимальное количесво поддерживаемых ACE

ACL с большим числом ACE более сложны в обслуживании. Использование большого числа ACE обычно указывает на плохое построение приложения. В большинстве таких случаев более грамотное использование групп будет более лучшим решением, чем раздутие ACL.

Реализации ACL в файловых системах ReiserFS и JFS не накладывают ограничений на максимальное число ACE, и, таким образом, этот предел ограничен лишь максимальным размером EA значений. В настоящее время размер EA ограничивается 64 Кб, или 8191 ACE, что является весьма большим значениям для практической реализации: кроме того, это довольно непрактично. Время, потраченное на проверку прав доступа в таком большом ACL, может оказаться довольно большим.

3.2.7 Совместимость

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

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

Во всех файловых системах, рассматриваемых в этой главе при использовании ядра, которое не поддерживает EAs для файловой системы, которая их поддерживает, EA будут игнорироваться. В ReiserFS, ядра, знающие о EA, прячут системный каталог, который содержит EAs, а при использовании ядер, не осведомленных о EAs, этот каталог становится видимым. Он до сих пор защищен от обычных пользователей через файловые ограничения.

Работа с файловыми системами, поддерживающими EA на ядрах, не поддерживающих EA, будет приводить к ряду неприятностей, когда будут удаляться файлы, имеющие EAs. В этом случае EAs не будут удалены, и это скажется в излишнем использовании дискового пространства. По крайней мере в Ext2 и Ext3 такие EAs, которые остались без своих объектов, могут быть удалены позже при помощи запуска проверки файловой системы.

Ядра, не знающие об ACL, используют традиционные биты файловых разрешений и не способны проверять разрешения, основываясь на определенных ACL. Алгоритм ACL в таких системах работать не будет.

3.3 ACL в Solaris

3.3.1 Более гибкая система безопасности

По мере распространения Solaris в коммерческих вычислительных комплексах появляется необходимость в использовании более гибких схем обеспечения безопасности доступа к файловым системам. Стандартно права доступа к файлу или каталогу определяются битами режима файла с помощью команды chmod(1). Файловый режим позволяет разрешать или запрещать права read, write и execute для трех различных типов пользователей - владельца файла (user), членов той же группы, что и владелец (group), и всех остальных пользователей системы (other). Такая схема не обеспечивает особой гибкости, поскольку не позволяет указать конкретный набор прав для данного пользователя или группы.