Призначення дозволів, таких як 0111 або 0333


17

Яка мета дозволів Linux, таких як 111 або 333 (тобто користувач може виконувати , але не може прочитати файл), якщо можливість виконання автоматично не передбачає можливість читання?


1
Чи є у вас приклад для такого налаштування? Я думаю, ти маєш рацію. Ви не можете виконати те, що не можете прочитати. Ці комбінації є просто теоретичними у просторі дозволів між 0000 та 0777. Зауважте, що для відображення восьмеричної бази числа слід додати провідний 0.
ikrabbe

6
Якщо це не сценарій (наприклад, shell-script), вам фактично не потрібен дозвіл на читання для виконання команди. "Нормальний" виконуваний файл - наприклад. su, bash або vi - просто потрібно встановити виконуваний біт, щоб користувач міг запустити його. Файл, який неможливо прочитати, неможливо скопіювати . Таким чином, не дозволяючи користувачу скопіювати важливу для безпеки команду (як-от su), він заважає зробити власну копію її - а також спробувати її розібрати. * BSD має кілька команд із виконанням, але не має дозволу на читання.
Баард Копперуд

Відповіді:


25

Я грав із цим і, мабуть, дозволи на виконання файлів не передбачають дозволу на читання. Бінарні файли можна виконувати, не читаючи:

$ 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

4
Це правильно, оскільки другий приклад використовує #! для запуску, оскільки він пропускає заголовок ELF і тому вимагає, щоб файл був читабельним, щоб він здогадався, який виконуваний файл його використовувати. Це звичайна ситуація, коли ви хочете захистити вміст файлів від копіювання в інші місця. Менеджер ліцензій - це поширений приклад, коли ви це бачили.
hspaans

1
Зауважте, що ви все ще можете читати двійковий файл, який виконується лише для виконання: unix.stackexchange.com/a/34294
小 太郎

6
@hspaans: Шебанг обробляється ядром, і ядро ​​не переймається химерними дрібницями, такими як дозволи. Це оболонка (або перекладач), якій потрібен доступ для читання. Ядро працює (скажіть) /bin/bash hw.sh, а потім bash намагається відкрити hw.shдля читання (і не вдається).
Кевін

2
Я для одного дуже сподіваюся , що ядро робить турботу про права доступу. Нічого іншого не робить. Страшне речення у публікації @ Кевіна означає, що ядро ​​вимагає дозволу на виконання файлів лише незалежно від того, чи вони використовують шебанг.
Еміль Йерабек підтримує Моніку

2
@ EmilJeřábek Ядро піклується про дозволи, вирішуючи, що може зробити процес подання заявки. Але оскільки компонент реалізує дозволи, він також може ігнорувати їх внутрішньо. Таким чином, він може читати рядок shebang, визначаючи, як виконати інтерпретований файл, або зчитувати вміст бінарного файлу, що виконується лише для виконання.
Бармар

16

це має сенс для каталогів, наприклад, якщо ви зберігаєте (секретно) виконувані файли в певному каталозі, а потім дозволяєте користувачам викликати ці файли, не маючи змоги бачити вміст каталогів (але знаючи, що певний файл є після того, як ви їх повідомили!). 333 порівняно з 111 дозволяє записувати / видаляти файли в / з цих каталогів, не маючи можливості бачити вміст каталогу.


5
У моєму Університеті ці дозволи використовувались для того, щоб скидати завдання в каталог, без того, щоб студенти бачили, що інші працюють. Лектором був старий скол.
DarkHeart

@DarkHeart Цікаво. Я сподіваюся, що вам довелося додати до назви файлів випадковий компонент, тому що в іншому випадку, якщо це не стимул намагатися скопіювати з однокласників, я не знаю, що таке.
PSkocik

5

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

То чому б не дати користувачам read-дозволу (і просто execute-пермізону)? Тому що файл, який не може прочитати користувач, не може бути скопійований і цим користувачем! Видаляючи readдозвіл, перешкоджає користувачам робити власні "особисті" копії виконуваних файлів - які вони згодом можуть зловживати (наприклад, отримати SUID=root on).

І не має writeдозволу, запобігає прискореному видаленню файлу.

Зауважте, що не надавати власника ні read-nor- writeдозволу є дещо рідкісним, але іноді це може бути хорошою ідеєю, щоб навіть ownerне просто видалити файл. Звичайно, що owner- не кажучи вже root- завжди можна обійти такі заходи, якщо не іншими способами, то просто за chmodдозволом на файл.


"може бути гарною ідеєю запобігти навіть ownerвидаленню файлу." - за винятком того, що вам не потрібен якийсь дозвіл на файл (читання, запис або виконання) для його видалення.
Селада

Виконані файли, готові лише до готовності, можуть бути використані, наприклад, якщо виконується вбудований пароль бази даних, який він використовує під час запуску для підключення до бази даних та виконує свою роботу, але не обов'язково розкривати пароль.
Celada

@Celada, це старе питання, але чи не такий підхід сприйнятливий до скидання пам’яті, шукаючи зрушення в області пам’яті /proc/${PID}/mapsі потім читаючи відповідні розділи пам’яті /proc/${PID}/mem? Або обмеження дозволів на файл виконуваного файлу також обмежує дозволи на читання відповідних розділів у пам'яті під час виконання? (Останнє здається малоймовірним, IMO.)
Спенсер D
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.