Я пытаюсь понять это поведение 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 неверно. Он должен прочитать
Это поведение, которое вы можете наблюдать , несмотря на то, что говорится в текущей странице руководства, в вашем вопросе. Это также поведение, указанное в проекте стандарта 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)проблему, упомянутую ранее.дальнейшее чтение
источник
S_IRWXGразрешения. Позвони мне, когда закончишь.Это поведение относится только к записям ACL POSIX. Причина здесь в том, что если у вас есть папка, и внутри этой папки есть файл, вы можете указать как rwx (например) папку и файл. Если групповые права доступа к файлу равны rw (что может быть типичным сценарием), маска, таким образом, дает acl эффективные разрешения rw, даже если ACL явно обозначает rwx.
С другой стороны, каталог, который почти всегда равен + x, имеет действующие разрешения маски ACL, также разрешающие + x.
Таким образом, эта маска в основном используется для разграничения разрешений между файлами и папками для набора ACL POSIX, так что файл не становится исполняемым, когда это обычно не должно быть.
источник