Як дозволу на роботу файлів працюють для "root" користувача?

У мене є такий файл:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Я переключив користувача rootв термінал, і я помітив таку поведінку:

• Я можу прочитати цей файл і написати до нього.

• Я не можу виконати цей файл.

• Якби я встановив xбіт у дозволах користувача ( ---x------) або групових дозволах ( ------x---) або інших дозволах ( ---------x) файлу, я міг би виконати цей файл.

Хтось може мені пояснити або вказати на підручник, в якому пояснюються всі правила, які застосовуються, коли rootкористувач має справу з файлами та каталогами?

Привілейований доступ до файлів і каталогів насправді визначається можливостями, а не лише наявністю rootчи ні. На практиці, rootяк правило, є всі можливі можливості, але бувають ситуації, коли всі / багато з них можуть бути відкинуті, або деякі передані іншим користувачам (їхні процеси).

Якщо коротко, ви вже описали, як перевірки контролю доступу працюють на привілейований процес. Ось як різні можливості насправді впливають на це:

Основна можливість тут полягаєCAP_DAC_OVERRIDE в тому , що процес, який має в ньому, може "обходити читання, запис файлів і виконання перевірок файлів". Це включає читання та запис у будь-які файли, а також читання, запис та доступ до каталогів.

Насправді це не стосується виконання файлів, які не позначені як виконувані. Про це йдеться в коментаріgeneric_permission ( fs/namei.c) перед тим, як перевірити доступ до файлів

Читання / запис ЦАПів завжди можна замінити. Виконані DAC-адреси перезаписуються, коли є щонайменше один біт exec.

І код перевіряє наявність принаймні одного xбіта, якщо ви намагаєтеся виконати файл. Я підозрюю, що це лише зручна функція, щоб запобігти випадковому запуску випадкових файлів даних та отримання помилок або незвичайних результатів.

У будь-якому випадку, якщо ви можете змінити дозволи, ви можете просто зробити виконувану копію та запустити її. _{(Хоча це може змінити теорію для встановлених файлів процесу, здатних змінити права доступу до файлів ( CAP_DAC_OVERRIDE), але не мали інших пов'язаних можливостей ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Але, маючи CAP_DAC_OVERRIDEможливість редагування /etc/shadowта подібних матеріалів, це приблизно однаково просто мати повний доступ до кореня.)}

Є також CAP_DAC_READ_SEARCHможливість, яка дозволяє читати будь-які файли та отримувати доступ до будь-яких каталогів, але не виконувати та записувати їх; і CAP_FOWNERце дозволяє процесу робити речі, які зазвичай зарезервовані лише для власника файлу, як-от зміна бітів дозволу та групи файлів.

Переосмислення липкого біта в каталогах згадується лише під CAP_FOWNER, тому, здається, цього CAP_DAC_OVERRIDEбуло б недостатньо, щоб ігнорувати це. (Це дасть вам дозвіл на написання, але зазвичай у клейких каталогах у вас це все-таки є і +tобмежує.)

_{(Я думаю, що тут спеціальні пристрої вважаються "файлами". Принаймні, generic_permission()є лише перевірка типу каталогів, але я не перевіряв поза цим ".)}

Звичайно, все ж є ситуації, коли навіть можливості не допоможуть вам змінити файли:

• деякі файли /procі /sys, оскільки вони насправді не фактичні файли
• SELinux та інші модулі захисту, які можуть обмежувати root
• chattrнезмінні +iта додавати лише +aпрапори на ext2 / ext3 / ext4, обидва вони зупиняють навіть root, а також запобігають перейменуванню файлів тощо.
• мережевих файлових систем, де сервер може здійснювати власний контроль доступу, наприклад, root_squashв NFS карти нікому не кореняться
• FUSE, який, я думаю, міг би зробити все, що завгодно
• кріплення лише для читання
• пристрої лише для читання

Це точно так, як ви помітили для дозволів за замовчуванням:

• Читання та запис:
  За замовчуванням користувач Root може отримати доступ до будь-якого файлу в системі. Ви можете видалити цей доступ, змінивши атрибути, як-от поясніть тут: chattr . Потім це пов'язано з можливостями.

• Виконати:
  Користувач Root не має дозволу на виконання, якщо не встановлено принаймні один із бітів виконання.

myFile.txtВиходить chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- означає, що немає дозволу для користувача, групи та інших.

Користувацький користувач має необмежену можливість змінювати цей файл. Читання / запис надається. Для виконання цього файлу кореневому користувачеві потрібно зробити його виконуваним у будь-якому випадку. (chmod 100, 010 або 001)

Режим виконання трактується дещо інакше, ніж інші режими.

Дозволи на читання та запис використовуються для забезпечення політики безпеки. rootКористувач , як правило , вільний від обмежень безпеки (є деякі винятки, такі як незмінні файли, а також сучасні функції , такі як можливості зробили це більш дрібнозернистий), тому інша назва для цього облікового запису є «суперкористувачем».

Дозвіл на виконання є скоріше дорадчим режимом, розрізняючи, чи призначений файл виконуваним файлом чи це лише дані. Через це навіть користувач root користується ним - він не має сенсу виконувати файл даних. Якщо жоден з дозволів на виконання не встановлений, root не може виконати файл; якщо хтось із них встановлений, він може. Звичайно, оскільки root також має дозвіл на зміну дозволів будь-якого файлу, обліковий запис може зробити файл виконуваним, якщо він цього хоче (якщо тільки файлова система не доступна лише для читання).

До речі, сценарії є цікавим випадком у цьому. Сценарії - це файли даних відповідного перекладача. Якщо у скрипту є #!рядок, ви можете виконати його як програму - інтерпретатор, названий у shebang, запускається з ім'ям файлу сценарію як аргументом. Але це буде зроблено лише тоді, коли буде встановлено дозвіл на виконання. З іншого боку, ви можете просто запустити перекладача безпосередньо, наприклад /bin/bash scriptname. Перекладачів хвилює лише те, чи зможуть вони прочитати файл, вони не перевіряють дозволи на виконання.

Дозвольте теоретично пояснити.

root користувач - король операційної системи.

Якщо файл або каталог мають будь-який дозвіл на зразок X для виконання, але нічого іншого, а хтось, як користувач Steve, має власний файл, то root також може виконати файл.

Завжди пам’ятайте, що в Linux root можна зробити все, що завгодно, для root немає обмежень.