Назначение разрешений, таких как 0111 или 0333

Какова цель разрешений Linux, таких как 111 или 333 (т. Е. Пользователь может выполнить , но не может прочитать файл), если возможность выполнения не подразумевает автоматическое чтение?

permissions chmod

— trolley813
источник

У вас есть пример для такой настройки? Я думаю, вы правы. Вы не можете выполнить то, что вы не можете прочитать. Эти комбинации являются просто теоретическими в области разрешений между 0000 и 0777. Обратите внимание, что следует добавить начальный 0, чтобы показать восьмеричное основание числа.

— Икраббе

Если это не скрипт (например, shell-скрипт), вам на самом деле не нужно разрешение на чтение для выполнения команды. «Нормальный» исполняемый файл - например, su, bash или vi - просто нужно установить исполняемый бит, чтобы пользователь мог его запустить. Файл, который не может быть прочитан, не может быть скопирован . Поэтому, не позволяя пользователю скопировать важную для безопасности команду (например, su), он не может сделать свою собственную копию, а также попытаться разобрать ее. * BSD имеет несколько команд с execute, но без разрешения на чтение.

— Баард Копперуд

Ответы:

Я играл с ним и, видимо, разрешения exec не подразумевают разрешения на чтение. Двоичные файлы могут быть исполняемыми без возможности чтения:

$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw 
hello world
$ cat hw
/bin/cat: hw: Permission denied

Я не могу выполнить сценарии, если только они не имеют биты разрешения на чтение и разрешение на выполнение:

$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh 
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied

— PSkocik
источник

Это правильно, так как во втором примере используется #! начать, так как он пропускает ELF-заголовок и поэтому требует, чтобы файл был читабельным, чтобы он мог угадать, какой исполняемый файл его использует. Это обычная ситуация, когда вы хотите защитить содержимое файлов от копирования в другие места. Диспетчер лицензий - типичный пример, где вы могли бы это увидеть.

— hspaans

Обратите внимание, что вы все еще можете прочитать исполняемый двоичный файл: unix.stackexchange.com/a/34294

— 小太郎

@hspaans: ядро обрабатывает шебанг, и ядру не нужны такие странные мелочи, как разрешения. Это оболочка (или интерпретатор), которой нужен доступ для чтения. Ядро работает (скажем) /bin/bash hw.sh, а затем bash пытается открыть hw.shдля чтения (и не удается).

— Кевин

Я, например, очень надеюсь, что ядро действительно заботится о разрешениях. Больше ничего не делает. Страшное предложение в посте @ Kevin означает, что ядру требуются только разрешения на выполнение для выполнения файлов, независимо от того, используют ли они шебанг.

— Эмиль Йержабек поддерживает Монику

@ EmilJeřábek Ядро заботится о разрешениях, когда решает, что может делать процесс приложения. Но так как это компонент, который реализует разрешения, он также может игнорировать их внутренне. Таким образом, он может прочитать строку shebang при определении того, как выполнить интерпретированный файл, или прочитать содержимое двоичного файла, предназначенного только для выполнения, в память.

— Бармар

это имеет смысл для каталогов, например, если вы храните (секретные) исполняемые файлы в определенном каталоге, а затем разрешаете пользователям вызывать эти файлы, не имея возможности видеть содержимое каталога (но зная, что после того, как вы проинформировали их, существует определенный файл!). 333 по сравнению со 111 позволяет записывать / удалять файлы в / из этих каталогов, не имея возможности видеть содержимое каталога.

— Афсин Топарлак
источник

В моем Uni-е эти разрешения использовались, чтобы помещать задания в каталог, чтобы учащиеся не видели, как работают другие. Лектор был старым школьником.

— DarkHeart

@DarkHeart Интересно. Я надеюсь, что вам пришлось добавить случайный компонент к именам файлов, потому что в противном случае, если это не является стимулом для копирования ваших одноклассников, я не знаю, что это такое.

— PSkocik

Очевидно, что не все комбинации являются такими полезными, но если взять ту, которую вы упомянули специально ... На самом деле вам не нужно readразрешение на выполнение файла - только executeразрешение - если рассматриваемый файл не является скриптом (например, shell-скрипт ( .sh), perl-script ( .pl) и т. д.). Обычные двоичные файлы могут быть выполнены только с executeразрешения. На * BSD-systmes несколько исполняемых файлов дают executeразрешение без разрешения read, особенно на «важные для безопасности» команды - например su.

Так почему бы не дать пользователям readразрешение (и просто executeразрешение)? Потому что файл, который не может быть прочитан пользователем, также не может быть скопирован этим пользователем! Удаление readразрешения запрещает пользователям создавать свои собственные «личные» копии исполняемых файлов, которые они впоследствии могут использовать (например, получить SUID=root on).

И, не имея write-permission, предотвращает случайное удаление файла.

Имейте в виду, что не давать ни read-нор- writeразрешения владельцу немного необычно, но иногда может быть хорошей идеей, чтобы даже ownerне удалить файл. Конечно, ownerне говоря уже о том, что rootтакие меры всегда можно обойти, если не другими способами, то просто с chmodразрешения файла.

— Баард Копперуд
источник

«Это может быть хорошей идеей, чтобы предотвратить даже ownerудаление файла». - за исключением того, что вам не нужно никакого разрешения на файл (чтение, запись или выполнение) для его удаления.

— Селада

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

— Селада

@Celada, это старый вопрос, но разве такой подход не будет восприимчив к сбросу памяти, просматривая смещения области памяти /proc/${PID}/mapsи затем считывая соответствующие разделы памяти /proc/${PID}/mem? Или ограничение разрешений для исполняемого файла также ограничивает разрешения на чтение соответствующих разделов в памяти во время выполнения? (Последнее кажется маловероятным, ИМО.)

— Спенсер Д