Я пытаюсь понять это поведение 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() не было такого поведения.Это было бы очень неудобно, потому что то, что люди традиционно ожидают от Unix, сломалось бы. Такое поведение хорошо служит вам, но вы знали об этом.
Жалко, что IEEE 1003.1e так и не стал стандартом и был отменен в 1998 году. На практике, четырнадцать лет спустя, это стандарт, который используется во многих операционных системах - от Linux через FreeBSD к Солярис - Реализовать.
Рабочий черновик 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 (), традиционно работавший на старых Unix без ACL, либо оставили бы зияющие дыры в безопасности, либо увидели бы, что они думают, что зияют дыры в безопасности:
Традиционные приложения Unix ожидают, что смогут запретить любой доступ к файлу, именованному каналу, устройству или каталогу с помощью chmod(…,000). При наличии ACL отключается только все права пользователя и группы, если старые S_IRWXG сопоставляется с CLASS_OBJ. Без этого установка старых разрешений на файлы на 000 не повлияет ни на один USER или GROUP Entry и другие пользователи, что удивительно, по-прежнему будут иметь доступ к объекту.
Временное изменение битов прав доступа к файлу на отсутствие доступа с помощью chmod 000 а затем их изменение снова было старым механизмом блокировки файлов, который использовался до того, как в Unix появились рекомендательные механизмы блокировки, которые - как видите - люди все еще используют.
Ожидается, что традиционные сценарии Unix смогут запускаться chmod go-rwx и в результате только владелец объекта может получить доступ к объекту. Очередной раз - как видите - это все-таки полученная мудрость двенадцать лет спустя. И снова это не работает, если старый S_IRWXG сопоставляется с CLASS_OBJ если он существует, иначе chmod команда не отключит ни одного USER или GROUP записи управления доступом, что приводит к тому, что пользователи, не являющиеся владельцами и не владеющими группами, сохраняют доступ к чему-то, что ожидается быть доступным только владельцу.
Система, в которой биты разрешений были отделены от других anded с ACL потребует, чтобы флаги прав доступа к файлам были rwxrwxrwx в большинстве случаев, что сильно сбило бы с толку многих приложений Unix, которые жалуются, когда видят то, что они считают доступным для записи всем.
Система, в которой биты разрешений были отделены от других ored с ACL будет иметь chmod(…,000) проблема, упомянутая ранее.
Это поведение применяется только к записям ACL POSIX. Причина этого в том, что если у вас есть папка и внутри этой папки существует файл, вы можете использовать acl как rwx (например) для папки и файла. Если групповые права доступа к файлу - rw- (что может быть типичным сценарием), маска, таким образом, дает acl действующие разрешения rw-, даже если ACL явно обозначает rwx.
С другой стороны, каталог, который почти всегда равен + x, имеет эффективные разрешения маски ACL, также разрешающие + x.
Таким образом, эта маска в основном используется для разграничения разрешений между файлами и папками для набора ACL POSIX, чтобы файл не стал исполняемым, хотя обычно этого не должно быть.