Почему chmod (1) в группе влияет на маску ACL?

Я пытаюсь понять это поведение Unix (которое я тестирую на Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Обратите внимание, что команда chmod (1) обновила маску ACL. Почему это происходит?

На странице SunOS есть следующее:

Если вы используете команду chmod (1) для изменения разрешений владельца группы файлов для файла с записями ACL, разрешения владельца группы файлов и маска ACL изменяются на новые разрешения. Помните, что новые разрешения маски ACL могут изменить действующие разрешения для дополнительных пользователей и групп, у которых есть записи ACL в файле.

Я спрашиваю, потому что мне было бы удобно, если бы chmod (1) не имел такого поведения. Я надеюсь, что, понимая, почему он делает то, что делает, я могу лучше спроектировать, как я настраиваю разрешения файловой системы.

Это не было бы удобно для вас, если chmod()бы не было такого поведения.

Это было бы очень неудобно, потому что вещи, которые люди традиционно ожидают, чтобы работать на Unixes, сломались бы. Это поведение служит вам хорошо, но вы знали это.

Жаль, что IEEE 1003.1e никогда не становился стандартом и был отменен в 1998 году. На практике, четырнадцать лет спустя, это стандарт, который фактически внедряют самые разные операционные системы - от Linux через FreeBSD до Solaris .

Рабочий проект IEEE 1003.1e № 17 интересен для чтения, и я рекомендую его. В добавлении B § 23.3 рабочая группа предоставляет подробное восьмистраничное обоснование довольно сложного способа работы ACL POSIX в отношении S_IRWXGфлагов разрешений старой группы. (Стоит отметить, что люди из TRUSIX предоставили такой же анализ десятью годами ранее.) Я не собираюсь копировать все это здесь. Прочитайте обоснование в проекте стандарта для деталей. Вот очень краткое сообщение :

• Руководство SunOS неверно. Он должен прочитать

  Если вы используете chmod(1)команду , чтобы изменить владельца разрешения на группу файлов на файл с записями ACL, либо с разрешения владельца группы файла или маску ACL заменяются на новые разрешения.

  Это поведение, которое вы можете наблюдать , несмотря на то, что говорится в текущей странице руководства, в вашем вопросе. Это также поведение, указанное в проекте стандарта POSIX. Если запись управления CLASS_OBJдоступом (терминология Sun и TRUSIX для ACL_MASK) существует, групповые биты chmod()устанавливают ее, в противном случае они устанавливают GROUP_OBJзапись контроля доступа.

• Если бы это было не так, приложения, которые делали различные стандартные вещи с помощью `chmod ()`, ожидая, что он будет работать как `chmod ()`, традиционно работавший на старых не-ACL Unix, либо оставляли бы дыры в безопасности, либо видели они думают, что зияют дыры в безопасности:

  • Традиционные приложения Unix предполагают, что смогут запретить любой доступ к файлу, именованному каналу, устройству или каталогу chmod(…,000). При наличии ACL это только отключает все пользовательские и групповые разрешения, если старые S_IRWXGсопоставлены CLASS_OBJ. Без этого, установка старых прав доступа к файлам , чтобы 000не влиять на любую USERили GROUPзапись и другие пользователи будут, как ни удивительно, по- прежнему имеют доступ к объекту.

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

  • Традиционные сценарии Unix предполагают, что смогут запускаться chmod go-rwxи заканчиваться только владельцем объекта, который может получить доступ к объекту. Опять же - как вы можете видеть - это все еще полученная мудрость двенадцать лет спустя. И опять же, это не работает, если только старая S_IRWXGкарта не сопоставлена, CLASS_OBJесли она существует, потому что в противном случае эта chmodкоманда не отключит какие- USERлибо GROUPзаписи или записи управления доступом, что приведет к тому, что пользователи, кроме владельцев и не владеющих группами, сохранят доступ к чему-то, что является Ожидается, что будет доступен только для владельца.

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

    Система, в которой биты прав доступа были отделены от orACL и отредактированы с помощью ACL, имела chmod(…,000)проблему, упомянутую ранее.

дальнейшее чтение

• Винфрид Трюмпер (1999-02-28). Краткая информация о Posix.1e
• Комитет по стандартам портативных приложений IEEE Computer Society (октябрь 1997). Проект стандарта для информационных технологий. Портативный интерфейс операционной системы (POSIX). Часть 1. Интерфейс прикладного программного обеспечения системы (API). Поправка №: Интерфейсы защиты, аудита и управления [Язык C] IEEE 1003.1e. Проект 17.
• Крейг Рубин (1989-08-18). Обоснование выбора функций списка контроля доступа для системы Unix . NCSC-TG-020-А. ДИАНА Издательство. ISBN 9780788105548.

Это поведение относится только к записям ACL POSIX. Причина здесь в том, что если у вас есть папка, и внутри этой папки есть файл, вы можете указать как rwx (например) папку и файл. Если групповые права доступа к файлу равны rw (что может быть типичным сценарием), маска, таким образом, дает acl эффективные разрешения rw, даже если ACL явно обозначает rwx.

С другой стороны, каталог, который почти всегда равен + x, имеет действующие разрешения маски ACL, также разрешающие + x.

Таким образом, эта маска в основном используется для разграничения разрешений между файлами и папками для набора ACL POSIX, так что файл не становится исполняемым, когда это обычно не должно быть.