установка бита «x» (исполняемый) с помощью ACL

Ваша проблема решена Почему мой сценарий оболочки подавляется пробелами или другими специальными символами? . Я просто кратко объясню, что здесь происходит.

Причина - для r в $ {documents [@]} . Поскольку расширение переменной не заключено в кавычки, вы используете операцию «split + glob»: значение каждого элемента массива разбивается на слова в соответствии со значением IFS , и каждое слово обрабатывается как шаблон подстановочного знака. Поскольку вы всегда устанавливаете IFS только на время чтения (см. Почему так часто используется `while IFS = read` вместо` IFS =; при чтении. .`? ), значение IFS в этот момент является значением по умолчанию, которое включает пробелы. Кроме того, если у вас есть поле, содержащее что-то вроде foo * , вы увидите имена файлов в текущем каталоге.Решением является для r в "$ {documents [@]}" , что является стандартным способом итерации по массиву: двойные кавычки превращают это в прямое разыменование переменной без разделения и подстановки, и [@] заставляет каждый элемент массива помещаться в отдельное слово.

Хотя установка IFS = $ '\ t' для всего скрипта, похоже, решает проблему, на самом деле это решает только половину проблемы: это не предотвращает глобализацию с $ {документы [@]} . Хотя вы можете отключить подстановку с помощью set -f , использование двойных кавычек более понятно.

4
12.04.2017, 11:27
2 ответа

Ответ на этот вопрос был дан в этих двух вопросах:

Как umask влияет на ACL?

https://superuser.com/questions/180545/setting-differing-acls-on-directories-and-files

Соответствующие биты взяты из man setfacl:

Поле perms представляет собой комбинацию символов, указывающих на >разрешения: чтение (r), запись (w), выполнение (x), выполнение только если файл является каталог или уже имеет разрешение execute для какого-то пользователя (X). В качестве альтернативы, поле perms может быть восьмеричной цифрой (0-7).

(Подчеркнуто мной)

Соответствующий раздел из первого вопроса в ответе @slm♦ следующий:

Подведем итог

  • Файлы не получат разрешение execute (маскирующее или эффективное). Не имеет значения, какой метод мы используем: ACL, umask или mask & ACL.

  • Каталоги могут получить разрешение на выполнение, но это зависит от того, как установлено маскирующее поле.

  • Единственный способ установить разрешения на выполнение для файла, который находится под ACL разрешениями - это установить их вручную с помощью chmod.

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

1
27.01.2020, 20:55

Я не думаю, что вы можете использовать ACL для принудительной установки бита разрешения .

Используя справочную страницу Linux ACL в качестве справки, ACL по умолчанию копируется в права доступа к файлу, но

  1. записи ACL доступа соответствуют битам прав доступа к файлу изменены так, что они не содержат разрешений, которые не содержащиеся в разрешениях, указанных параметром режима [передается в open () , creat () и т. Д.] .

Поскольку битовая маска разрешения соответствует битам разрешения группы, здесь она затрагивается.

Если нет ACL по умолчанию, вместо него используется umask , но та же самая маскировка по-прежнему выполняется.

Что, конечно, согласуется с обычным обычаем программы ограничивать разрешения теми, которые она передает в open при создании файла, будь то исключение разрешений на выполнение в режиме 0666 или исключение доступа других пользователей к файлу в режиме 0600 .

3
27.01.2020, 20:55

Теги

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