Тема: «Изучение контроля доступа мультисервисных сетей»
Цель: - Изучить списки контроля доступа и определение прав доступа различным категориям пользователей
Образовательные результаты, заявленные во ФГОС третьего поколения.
Студент должен:
уметь:
- осуществлять конфигурирование сетей;
- проводить мониторинг работоспособности оборудования информационно-коммуникационных сетей связи;
- анализировать результаты мониторинга и устанавливать их соответствие действующим отраслевым нормам:
- производить настройку интеллектуальных параметров (VLAN, STP, RSTP, MSTP, ограничение доступа, параметры QoS) оборудования технологических мультисервисных сетей.
знать:
- основы построения и администрирования ОС «Linux»;
- техническое и программное обеспечение персонального компьютера
Краткие теоретические и учебно-методические материалы по лабораторной работе
Традиционная девятибитовая система контроля доступа (access control system — ACL) "владелец/группа/другие" позволяет решать большинство задач администрирования. Хотя ей присущи явные ограничения, она хорошо согласуется с традициями (кое-кто может сказать "с прошлыми традициями") простоты и предсказуемости UNIX.
Практически все другие операционные системы используют значительно более сложный метод управления доступом к файлам: списки управления доступом или ACL. Каждому файлу или каталогу может соответствовать список ACL, в котором перечислены правила установки прав доступа к данному файлу или каталогу. Каждое правило в списке ACL называется записью управления доступом (access control entry — АСЕ).
В общем, запись контроля доступа идентифицирует пользователя или группу, к кото-рой она применяется, и определяет набор привилегий, которыми наделяются эти пользователи. Списки ACL не имеют фиксированной длины и могут содержать определения прав множества пользователей или групп. Большинство операционных систем ограничивает длину отдельного списка ACL, но это ограничение может быть довольно слабым (обычно 32 записи), которое достигается не часто.
Более сложные системы позволяют администраторам указывать частичные наборы прав или отрицательные права, а некоторые из систем поддерживают наследование, которое позволяет определять права доступа для передачи их вновь создаваемым элементам файловых систем.
Конечно, системы ACL предоставляют больше возможностей, чем традиционная модель UNIX, но они и сложнее ее на порядок как для администраторов, так и для разработчиков программ. Используйте их с большой осторожностью. Они не только сложнее в использовании, но и могут порождать проблемы при использовании в сочетании с "не имеющими понятия" об ACL-списках системами резервного копирования, узлами NFS и даже такими простыми программами, как текстовые редакторы.
Списки ACL тяготеют к беспорядку, и поэтому со временем они становятся непригодными для управления.
Краткий обзор развития UNIX-списков ACL
Рассмотрим различные системы ACL, которые поддерживаются в UNIX и Linux, а также наборы команд, предназначенные для управления ими. Но сначала необходимо ответить на вопрос: "Как эти списки ACL превратились в катастрофу?"
Обычно объект рассматривается как история политики, денег и ветвлений. В данном случае базовое понимание истории помогает наложить на реальность некоторую структуру.
Подкомитет POSIX впервые начал работать над ACL для UNIX в средине 1990-х годов. В первом приближении модель POSIX ACL просто расширила традиционную UNIX-систему прав доступа (rwx), чтобы удовлетворить потребности в привилегиях различных пользователей и групп.
К сожалению, проект POSIX не стал официальным стандартом, и рабочая группа была расформирована в 1998 году. Тем не менее некоторые компании реализовали системы POSIX ACL "на свой вкус". Нашлись и такие компании, которые создали собственные системы ACL. Но поскольку в этой области лидер четко не обозначился, все реализации выглядели по-разному.
Тем временем для систем UNIX и Linux стало практически нормой использовать файловые системы совместно с Windows, которая имеет собственные ACL-соглашения. Здесь напряжение в нашей истории возрастает, поскольку Windows создает множество функций, которых нет ни в традиционной модели UNIX, ни в ее эквиваленте POSIX ACL. Кроме того, списки ACL в системе Windows семантически более сложные; например, они позволяют использовать отрицательные права (записи с "отказом" в правах) и предусматривают усложненную схему наследования.
Архитекторы-разработчики версии 4 протокола NFS — стандартного UNIX-протокола по совместному использованию файлов — стремились включить в свое детище системы ACL как элемент первостепенной важности. Из-за "разногласий" между UNIX и Windows и несовместимости между реализациями UNIX ACL стало очевидно, что на стороне соединения NFSv4 могут оказаться системы совершенно разных типов. Все они могут понимать "язык" NFSv4 ACL, POSIX ACL, Windows ACL или совсем не понимать системы ACL. Стандарт NFSv4 должен иметь возможность взаимодействовать с различными мирами без особых сюрпризов и проблем с безопасностью.
В таких условиях неудивительно, что системы NFSv4 ACL являются, по сути, объединением всех ранее существовавших систем. Они представляют собой строгое супермножество систем POSIX ACL, поэтому любая система POSDC ACL может быть представлена как NFSv4 ACL без потери информации. В то же время системы NFSv4 ACL обеспечивают все биты прав доступа, которые предусмотрены в системах Windows, а также имеют большинство семантических свойств Windows.
Реализация списков ACL
Теоретически ответственность за поддержку и функционирование систем ACL можно было бы переложить на ряд других компонентов операционной системы. Системы ACL могли бы быть реализованы ядром от имени всех файловых систем, отдельными файловыми системами или, может быть, такими высокоуровневыми программами, как серверы NFS и CIFS.
На практике только файловые системы могут реализовать списки ACL ясно, надежно и с приемлемой производительностью. Следовательно, поддержка ACL зависит от операционной системы (ОС) и файловой системы. Файловая система, которая поддерживает списки ACL в одной ОС, может не поддерживать их в другой или может предусматривать несколько другую реализацию, поддерживаемую другими командами.
В UNIX стандартные системные вызовы, которые обеспечивают управление файлами (open, read, unlink и пр.), не создают никаких возможностей для поддержки ACL. Тем не менее они продолжают прекрасно работать в системах со списками ACL благодаря тому, что базовые файловые системы выполняют собственные действия по контролю прав доступа. Операции, которые не разрешены релевантной системой ACL, просто не выполняются и возвращают общий код ошибки в виде "отсутствия прав доступа".
ACL-ориентированные программы для чтения или установки файловых списков ACL используют отдельный системный вызов или библиотечную утилиту. Если в операционную систему добавляется ACL-поддержка, то обычно модернизируются такие распространенные утилиты, как Is и ср, чтобы обеспечить хотя бы минимальную поддержку ACL (например, с помощью команды ср -р, которая должна хранить списки ACL, если таковые имеются). Кроме того, система должна добавлять новые команды или командные расширения, которые бы разрешили пользователям читать и устанавливать списки ACL из командной строки. К сожалению, эти команды не стандартизированы в операционных системах.
Поскольку реализации списков ACL зависят от конкретной файловой системы и операционные системы поддерживают несколько реализаций файловых систем, во многих системах предусматривается поддержка нескольких типов списков ACL. Даже отдельно взятая файловая система может предложить несколько вариантов ACL, как в системе JFS2 (IBM). Если возможно использование нескольких систем ACL, команды по управлению ими могут быть одинаковыми или различными — все зависит от конкретной системы.
Системная поддержка списков ACL
Рассмотрим особенности поддержки списков ACL в разных системах UNIX и Linux, поскольку трудно описать эту область общими словами.
На момент написания (2010 г.) POSIX-ориентированные ACL-сис-темы играют ведущую роль по реализации и использованию, но NFSv4 ACL прогрессируют особенно быстро и, по всей вероятности, станут стандартом де-факто.В настоящее время только системы ZFS (компания Sun) и JFS2 (IBM) обладают собственной поддержкой NFS4v4 ACL.
В Linux ACL-списки в POSIX-стиле поддерживаются файловыми системами ReiserFS, XFS, JFS, Btrfs и семейством ext. Обычно они отключены по умолчанию, но с помощью команды mount с опцией -о acl их можно включить. Управлять записями POSIX ACL позволяют команды getfacl и setfacl.
Системы Solaris поддерживают POSIX ACL на основе более старой файловой soLaris системы UFS и NFSv4 ACL на базе системы ZFS. Версии Solaris-команд ls и chmod модифицированы для отображения и редактирования обоих типов списков ACL10. В системе Solaris предусмотрены команды setfacl и getfacl, которые отчасти подобны используемым в дистрибутивах Linux, но в действительности они служат только для совместимости и работают лишь для POSEX ACL.
В операционной системе HP-UX разработана собственная подсистема ACL для собственной файловой системы HFS (High-performance File System — высокопроизводительная файловая система). Когда компания HP приняла VxFS (Veritas) в качестве своей главной файловой системы, она также включила поддержку ACL в стиле POSIX11. К сожалению, эти две системы ACL управляются различными наборами команд. Система HFS в настоящее время не имеет большого практического значения, но команды HFS ACL остаются в силе для совместимости. В этой книге системы HFS ACL не рассматриваются.
В AIX файловая система JFS2 поддерживает собственную систему ACL, известную как AIXC. Как и AIX 5.3.0, система JFS2 также поддерживает списки ACL в стиле NFSv4. В AIX используются одинаковые команды (aclget, aclput и acledit) для управления обоими типами списков ACL, а для упрощения перехода из одного формата в другой используется утилита aclconvert. В этой книге системы AIXC не рассматриваются.
Обзор POSIX ACL
Списки POSIX ACL поддерживаются во многих файловых системах Linux и в порте файловой системы VxFS (компания HP-UX), именуемой JFS. Они также присутствуют в системе Solaris только для файловой системы UFS.
Списки POSIX ACL Linux представляют собой практически простое расширение стандартной 9-битовой UNIX-модели прав доступа. Система поддерживает только права чтения, записи и выполнения. Такие дополнительные атрибуты, как setuid- и дополнительные биты, обрабатываются исключительно традиционными битами определения режима.
Списки ACL позволяют устанавливать биты rwx независимо для любой комбинации пользователей и групп.
Убедитесь, что в вашей переменной среды PATH путь /bin указан перед путем /usr/gnu /bin, что позволит вам получить именно Solaris-версии команд 1а и chown, а не GNU-версии.
Для того чтобы дезориентировать своих клиентов и держать их в покорном неведении, компания HP использует стратегию "похищения" имен существующих файловых систем, применив их к запатентованным продуктам. Например, файловая система HFS компании HP была названа так специально, чтобы ее можно было легко спутать с файловой системой Hierarchical File System компании Apple, также именуемой HFS. Компания HP для своего порта VxFS выбирает название "JFS", чтобы пользователям было трудно отличить его от имени JFS, которое выбрала компания IBM для собственной файловой системы.
Пользователей и группы можно задавать именами или идентификаторами UID/GID. Точное число записей, которое может содержать список ACL, зависит от реализации файловой системы и колеблется от 25 в XFS до практически неограниченного значения в файловых системах ReiserFS и JFS. Файловые системы ext допускают использование до 32 записей, что, вероятно, вполне оправдано с точки зрения обеспечения возможности управления списком.
Взаимодействие между традиционными режимами и списками ACL
При использовании ACL файлы сохраняют свои исходные биты режима, но при этом автоматически поддерживается целостность атрибутов, и два набора прав доступа не могут вступить в конфликт. Ниже приведен пример (используется синтаксис Linux-команд) автоматического обновления записей ACL в ответ на изменения, выполненные "старой" командой chmod.
$ touch /tmp/example $ ls -1 /tmp/example
-rw-rw-r— 1 garth garth 0 Jun 14 15:57 /tmp/example
$ getfacl /tmp/example
getfacl: Removing leading 1/1 from absolute path names
#file: tmp/example
#owner: garth
#group: garth user::rw- group::rw- other::r—
$ chmod 640 /tmp/example
$ getfacl —omit-header /tmp/example
user::rw-
group::r—
other::
Эта принудительная целостность атрибутов позволяет более старым программам, которые даже не подозревают о существовании ACL, достаточно успешно работать в использующей эти списки среде. Однако существует и определенная проблема. Несмотря на то что ACL-запись group:: в приведенном примере вроде и отслеживает средний набор традиционных битов режима, это не всегда так.
Для того чтобы понять, в чем здесь дело, предположите, что унаследованная программа очищает биты разрешения записи во всех трех наборах прав традиционного режима (например, chmod ugo-w файл). Понятно, что целью выполнения этой команды является запрет выполнения записи в файле кем-либо. Но что произойдет, если результирующий список ACL выглядит следующим образом:
user:: г—
group:: г—
group:staff:rw-
other:: г—
С точки зрения унаследованной программы файл выглядит неизменяемым, хотя в действительности он доступен для записи для любого члена группы staff. Подобная ситуация нежелательна. Для снижения вероятности недоразумений приняты следующие правила.
По определению записи user:: и other:: списка ACL идентичны битам режима "владелец" и "другие" традиционного режима файла. Изменение режима ведет к изменению соответствующих записей ACL и наоборот.
Во всех случаях эффективными правами доступа, предоставляемыми владельцу файла и пользователям, которые не указаны как-либо иначе, являются те, которые указаны в соответствующих записях user:: и other:: списка ACL.
Если файл не имеет явно определенного списка ACL или имеет ACL, который состоит только из одной записи user: :, одной записи group:: и одной записи other::, эти записи идентичны трем наборам традиционных битов режима. Именно такой случай продемонстрирован в приведенном выше примере применения команды getfacl. (Подобный ACL называют минимальным, и он не требует действительной реализации в виде логически отдельного ACL.)
В более сложных списках ACL традиционные биты режима соответствуют специальной записи ACL, называемой "маской", а не записи group::. Маска ограничивает доступ так, что ACL может предоставлять права всем названым пользователям, всем названым группам и группе, заданной по умолчанию.
Иначе говоря, маска определяет верхний предел прав доступа, которые система ACL может присваивать отдельным группам и пользователям. Концептуально эта маска аналогична команде umask, за исключением того, что маска ACL действует всегда и указывает предоставленные, а не отобранные права. Записи ACL для названых пользователей, названых групп и группы, заданной по умолчанию, могут содержать права доступа, отсутствующие в маске, но ядро будет просто их игнорировать.
В результате традиционные биты режима не в состоянии уменьшить права, глобально предоставленные списком ACL. Более того, удаление бита из части группы традиционного режима ведет к удалению соответствующего бита в маске ACL и, следовательно, к лишению этих прав всех пользователей, кроме владельца файла и тех, кто относится к категории "другие".
При расширении списка ACL, приведенного в предыдущем примере, для включения в него записей конкретного пользователя и группы команда setfacl автоматически определяет соответствующую маску.
$ ls -1 /tmp/example
-rw-r --1 garth garth 0 Jun 14 15:57 /tmp/example
$ setfacl -m user::r,user:trent:rw,group:admin:rw /tmp/example $ Is -1 /tmp/example
-r—rw --+ 1 garth garth 0 Jun 14 15:57 /tmp/example
$ getfacl —omit-header /tmp/example
user:: г— user:trent:rw- group::r— group:admin:rw- mask::rw- other::
Как видите, Linux-версия команды setfacl генерирует маску, которая позволяет вступить в действие всем правам, предоставленным в списке ACL. Для определения маски вручную нужно включить ее в список записей ACL, переданный команде setfacl, либо использовать опцию -п, чтобы помешать ее повторному генерированию командой setfacl. (В системе Solaris команда setfacl по умолчанию не пересчитывает запись с маской; поэтому для ее повторного генерирования используйте флаг -г.)
Обратите внимание на то, что в результате выполнения второй команды Is -1 (после команды setfacl) в конце режима файла выводится знак "+", означающий, что с ним теперь связан реальный список ACL. Первая команда Is -1 не выводит знак "+", поскольку на данный момент список ACL является "минимальным". Другими словами, он полностью описан 9-битовым режимом, и поэтому нет необходимости хранить его отдельно.
Следует иметь в виду, что применение традиционной команды chmod для манипулирования правами доступа группы в файле, связанном с ACL, сказывается только на маске. Продолжим рассмотрение предыдущего примера.
$ chmod 770 /tmp/example $ Is -1 /tmp/example
-rwxrwx -+ 1 garth staff 0 Jun 14 15:57 /tmp/example
$ getfacl —omit-header /tmp/example
user::rwx user:trent:rw- group::r— group:admin:rw- mask::rwx other::
В данном случае результат выполнения команды Is вводит в заблуждение. Несмотря на обширные права, предоставленные группе, ни один из ее членов в действительности не обладает правами выполнения файла на одном лишь основании принадлежности к группе. Для того чтобы предоставить это право, придется отредактировать список ACL вручную.
Определение прав доступа
При попытке получения процессом доступа к файлу эффективный UID сравнивается с UID владельца файла. Если они совпадают, права доступа определяются правами user:: в списке ACL. В противном случае, при наличии соответствия записи конкретного пользователя в ACL, права определяются этой записью и маской ACL. При отсутствии подходящей записи конкретного пользователя файловая система пытается найти подходящую запись группы, предоставляющую запрошенные права. Эти записи также обрабатываются в сочетании с маской ACL. При отсутствии подходящей записи права Доступа определяются записью other::.
Наследование списка ACL
Списки ACL каталогов могут содержать записи, определенные "по умолчанию", которые передаются спискам ACL новых файлов и подкаталогов внутри них. Подкаталоги получают свои записи как в форме записей активного ACL, так и в форме записей, заданных по умолчанию. Следовательно, исходные заданные по умолчанию записи могут со временем распространяться по нескольким уровням иерархии каталогов.
Связь между родительским и дочерними ACL не сохраняется при копировании заданных по умолчанию записей. Изменения в заданных по умолчанию записях родительского каталога не отражаются в списках ACL существующих подкаталогов.
Списки NFSV4 ACL
Рассмотрим характеристики списков NFSv4 ACL и синтаксис Solaris-команд, используемых для их установки и просмотра. Система AIX также поддерживает списки NFSv4 ACL, но для работы с ними использует другие команды (aclget, aclput, acledit и пр.). Не останавливаясь на деталях синтаксиса конкретного набора команд, сосредоточимся на теоретической основе, не зависящей от системы. Понимая основные принципы, нетрудно будет освоить соответствующие команды в интересующей вас системе.
С точки зрения структуры, списки NFSv4 ACL аналогичны спискам ACL в системе Windows. Основное различие между ними состоит в спецификации категории, к которой относится запись контроля прав доступа.
В списках ACL обеих систем запись хранится в виде строки. Для списков Windows ACL эта строка обычно содержит идентификатор защиты Windows (Windows security identifier — SID), в то время как NFSv4-cTpoKa, как правило, имеет такой формат: user: имя_ пользователя или group: имя_группы. Она также может иметь один из специальных маркеров: owner@, group@ или everyone®. В действительности эти "специальные" записи можно считать самыми популярными, поскольку они связаны с битами режима доступа, установленными для каждого файла.
Такие системы, как Samba, которые разделяют файлы между системами UNIX и Windows, должны обеспечивать определенный способ преобразования данных между Windows и NFSv4.
Модель прав доступа систем Windows и NFSv4 отличается большей детализацией по сравнению с традиционной UNIX-моделью "чтение-запись-выполнение". Рассмотрим ее основные отличительные черты.
В системе NFSv4 разрешение на создание файлов в каталоге отличается от разрешения создавать подкаталоги.
В системе NFSv4 предусмотрен отдельный бит разрешения на "добавление".
В системе NFSv4 предусмотрены отдельные биты разрешения на чтение и запись для данных, файловых атрибутов, расширенных атрибутов и ACL.
В системе NFSv4 реализовано управление возможностью пользователей менять владельца файла посредством стандартной системы ACL. В традиционной моде ли UNIX возможность менять владельца файла обычно имеет только суперпользователь.
Разрешения (права доступа), которые могут назначаться в системе NFSv4, а также однобуквенные коды, используемые для их представления, и имена, отображаемые и принимаемые Solaris-командами ls и chmod.
Некоторые права доступа имеют несколько имен, поскольку они представлены одинаковым значением флага, но интерпретируются по-разному для файлов и каталогов. Этот вид перегрузки, вероятно, вам знаком из традиционных UNIX-систем управления доступом. (Например, код х в традиционной системе означает право на выполнение обычного файла и "транзитное" разрешение применительно к каталогу.)
Несмотря на то что в NFSv4 модель прав доступа достаточно детализирована, отдельные разрешения должны быть очевидны, т.е. не должны требовать дополнительных разъяснений. Разрешение "synchronize" позволяет клиенту указать, что модификации файла должны быть синхронизированы, т.е. вызовы, связанные с записью данных, не должны завершиться до тех пор, пока данные не будут реально сохранены на диске.
Расширенный атрибут — это именованная часть данных, которая сохраняется вместе с файлом. Большинство современных файловых систем поддерживает такие атрибуты, хотя они пока не нашли широкого применения. В настоящее время расширенные атрибуты, в основном, используются для сохранения самих списков ACL. Однако модель прав доступа в NFSv4 предусматривает обработку списков ACL отдельно от других расширенных атрибутов.
Объекты NFSv4, для которых можно задавать права доступа
В дополнение к обычным спецификаторам user: имя_пользователя или group: Имя группы, в системе NFSv4 определено еще несколько объектов, которые могут быть Указаны в списке ACL. Самыми важными из них являются owner@, group® и everyone®, которые связаны с традиционными категориями в 9-битовой модели прав доступа.
В системе NFSv4 спецификация (RFC3530) определяет еще несколько таких специальных объектов, как dialup@ и batch®. С точки зрения системы UNIX все они немно-го стРанные. Насколько нам известно, их назначение — способствовать совместимости с Windows. Система NFSv4 отличается от POSIX по ряду признаков. Прежде всего, тем, что NFSv4 не имеет стандартного объекта, используемого по умолчанию для управления ACL-наследованием. Вместо этого любая отдельная запись управления доступом (АСЕ) может быть помечена как передающаяся по наследству. Кроме того, система NFSv4 не использует маску для согласования прав доступа, заданных в режиме файла с помощью списка ACL. Режим, необходимый для согласования с параметрами, задаваемыми для owner@, group@ и everyone®, а также файловые системы, которые реализуют списки NFSv4 ACLs, должны сохранять эту совместимость при обновлении режима либо списка ACL.
Определение прав доступа
В системе POSDC ACL файловая система пытается сопоставить идентификатор пользователя с одной, но самой важной записью управления доступом. Эта запись (АСЕ) затем предоставляет полный набор управляющих прав для доступа к файлу.
Система NFSv4 отличается тем, что АСЕ может задавать только частичный набор прав. Каждая запись NFSv4 АСЕ либо разрешает, либо запрещает доступ. Запись действует больше как маска, чем официальная спецификация всех возможных прав. К любой конкретной ситуации можно применить несколько записей АСЕ.
Принимая решение о том, разрешать ли выполнение конкретной операции, файловая система считывает список ACL и обрабатывает записи АСЕ до тех пор, пока все затребованные права не будут разрешены или какое-то затребованное право не будет отклонено. При этом рассматриваются только те записи АСЕ, строки которых соответствуют текущему идентификатору пользователя.
Файловая система может "пройти" список NFSv4 ACL до конца, не получив определенного ответа на запрос прав доступа. В этом случае стандарт NFSv4 считает полученный результат неопределенным, однако большинство существующих реализаций выберут доступ с отказом, во-первых, потому, что такое соглашение используется в системе Windows, и, во-вторых, потому, что это — единственный вариант, который имеет смысл.
Наследование списка ACL
Подобно спискам POSIX ACL, списки NFSv4 ACL позволяют созданным объектам наследовать записи управления доступом от включающего их каталога. Однако система NFSv4 при небольшом выигрыше в возможностях гораздо более запутана по сравнению с POSIX. И вот почему.
Любая запись может быть отмечена как наследуемая. Признаки наследования для создаваемых подкаталогов (disinherit или d) и создаваемых файлов (f ile_ inherit или f) устанавливаются по отдельности.
Можно применять различные записи управления доступом для новых файлов и новых каталогов путем создания отдельных записей управления доступом в родительском каталоге с соответствующими признаками. Можно также применить одну запись АСЕ ко всем новым дочерним записям (любого типа) за счет включения обоих флагов d и f.
С точки зрения определения прав доступа, записи управления доступом оказывают одинаковое влияние на родительский (исходный) каталог независимо от того, наследуемый он или нет. Если вы хотите применить запись к дочернему, но не к родительскому каталогу, включите для соответствующей записи АСЕ флаг inherit_only (i).
Новые подкаталоги обычно наследуют две копии каждой записи АСЕ: с отключенными флагами наследования (применяется к самому подкаталогу) и с включенным флагом inheritonly (устанавливает новый подкаталог для распространения своих передаваемых по наследству записей АСЕ). Вы можете подавить создание этой второй записи АСЕ включением флага no_propagate (п) для копии записи АСЕ родительского каталога. Конечный результат состоит в том, что запись АСЕ распространяется только на прямых потомков исходного каталога.
Не путайте распространение записей управления доступом с настоящим наследованием. Установка связанного с наследованием флага для записи АСЕ просто означает, что данная запись АСЕ будет скопирована в новые записи. Она не создает никаких постоянных отношений между родителем и его потомком. Если вы позже измените записи АСЕ для родительского каталога, дочерние каталоги при этом не будут обновлены.
Взаимодействие между списками ACL и традиционными режимами
Рассмотрим некоторые аспекты преобразования режимов в списки ACL. Во-первых, обратите внимание на то, что записи group® и everyone® в приведенном выше гримере отличаются друг от друга, несмотря на то что соответствующие части в коде режима (r-х) совпадают. И это не потому, что правила преобразования различны для категорий group® и everyone®; все дело в том, что определенные права доступа невозможно реально экстраполировать из традиционного режима.
Эти "неустановленные" биты прав доступа принимают стандартные значения благодаря дополнениям только к записям АСЕ категории everyone®. Права доступа write_ xattr, writeattributes, write_acl и write_owner всегда означают запрещенный доступ, а права read_xattr, read_attributes, read_acl и synchronize всегда разрешены. Если вы "выведите" эти права из набора everyone®, то увидите, что оставшиеся записи АСЕ для категории everyone® такие же, как для категории group®.
Безусловно, эти "совместимые" права применяются только к тривиальным спискам ACL. Редактируя напрямую список ACL, вы можете установить биты в любой комбинации.
Режим и список ACL должны оставаться совместимыми, поэтому при корректировании одного из этих вариантов другой обновляется автоматически. Файловая система ZFS успешно определяет соответствующий режим для заданного списка ACL, но ее алгоритм для генерирования и обновления списков ACL в ответ на изменения режимов остается рудиментарным. Результаты с функциональной точки зрения нельзя назвать некорректными, но они зачастую излишне детализированы, нечитабельны и с трудом поддаются интерпретации. В частности, для категорий owner®, group® и everyone® система может сгенерировать несколько наборов записей (и притом противоречивых), которые будут зависеть от порядка вычисления.
Возьмите себе за правило никогда не трогать режим файла или каталога после применения списка ACL. В самом худшем случае с помощью команды chmod А- файл удалите список ACL и начните все заново.
|
