Вопросы Теги

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

Крупнейший 'Doh!' недели я считаю - жаль чувак.

Сами диски не будут физически повреждены, это просто, что Вы уничтожили массив путем удаления второго диска, прежде чем первый восстановил - я> 90%, уверенных, что массив является тостом. В основном Вы не должны были удалять их вообще, в то время как живой, если Вы абсолютно имели Вам, должен был ожидать массива для восстановления прежде, чем сделать второй диск.

Это, переустанавливают/время восстановления, я боюсь - Ваших данных не стало.

17
задан 23 January 2012 в 18:34
2 ответа

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

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

Жаль, что 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 ()` традиционно работал со старыми Unix без ACL, либо оставит зияющие дыры в безопасности, либо увидит, что они считают зияющими дырами в безопасности:

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

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

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

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

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

Дополнительная литература

24
ответ дан 2 December 2019 в 20:31

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

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

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

0
ответ дан 2 December 2019 в 20:31

Теги

Похожие вопросы