Почему 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) не имел такого поведения. Я надеюсь, что, понимая, почему он делает то, что делает, я могу лучше спроектировать, как я настраиваю разрешения файловой системы.

Источник

2 ответа

Решение

Это было бы не удобно для вас, если 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 записи управления доступом, ведущие к пользователям, отличным от владельцев и не владеющих группами, сохраняющим доступ к чему-то, что, как ожидается, будет доступно только владельцу.

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

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам