У дозволі відхилено лише один файл у каталозі як користувач root у файловій системі ext3 під ОС RAIDiator

У мене є вікно ReadyNAS під назвою "сховище", яке, на мою думку, засноване на Debian. Я можу ввійти в нього як корінь. Я намагаюся переналаштувати веб-сервер, але я стикаюся з проблемою дозволу на файли, яку я просто не розумію. Я нічого не можу зробити /etc/frontview/apache/apache.pemнавіть з root! Схоже, немає спеціальних дозволів порівняно з іншими файлами в тому самому каталозі, і я можу працювати з ними.

storage:~# whoami 
root
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

Що настільки особливого у цьому файлі, що його не можна торкатися? Я не можу її видалити. Я не можу змінити дозволи на нього. Я не можу змінити власника.

Каталог, здається, добре. У ньому залишилося місце, він не встановлений лише для читання. Насправді я можу редагувати інші файли в одному каталозі.

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /

— Стівен Остерміллер
джерело

Будь ласка, покажіть вихід ls -ld /etc/frontview/apacheта df /etc/frontview/apache. Може папка знаходиться на дисковому просторі ro?

— Ned64

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

— Стівен Остерміллер

@RunCMD Я додав більш конкретну інформацію до заголовка та тегів. Файлова система вказана як ext3, тому ext3, схоже, підтримує незмінні # mount::/dev/hdc1 on / type ext3 (rw,noatime)

— Стівен Остерміллер

Solaris не підтримує ext3 або ARM-процесори, тому, ймовірно, не заснований на Solaris.

— alanc

Я зняв Соларіс з питання. Подальше читання може базуватися на Debian Etch.

— Стівен Остерміллер

Я щойно знайшов проблему. Атрибут "незмінний" був встановлений у цьому файлі. lsне показує це. Щоб переглянути його, вам потрібна інша команда:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

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

# chattr -i apache.pem
# touch apache.pem

— Стівен Остерміллер
джерело

Я натиснув на це питання в "гарячих питаннях мережі", щоб сказати вам перевірити розширені атрибути, але я думаю, ви вже це зробили. (IDK, чому GNU lsне має можливості перераховувати атрибути. Я забуваю, але, можливо, навіть системний виклик для їх запиту не є портативним, тому, мабуть, було простіше просто реалізувати їх в окремій утиліті.)

— Peter Cordes

@PeterCordes Я згоден. Я впевнений, що встановив цей біт після Googling щось на кшталт "зупинити оновлення від перезапису файлу", але це було років тому, і я явно забув це робити. Було б добре, якби lsпоказав цей біт, або якщо будь-яка інша команда, яку я використав, мала більш корисні (і конкретні) повідомлення про помилки щодо того, чому в дозволах відмовлено.

— Стівен Остерміллер

Всім touchвідомо, що системний виклик, з яким він намагався ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) не вдався EACCESS. (Використовуйте strace -efile touch apache.pemдля перегляду файлових системних дзвінків, які він робить). Як йдеться у підручнику для цього системного виклику , існує багато можливих причин EACCESS, і багато з них включають батьківські каталоги, а не сам файл. Написати код, щоб точно вивести, чому системний виклик повернув помилку, це було надзвичайно важко, оскільки різні файлові системи та ОС різні ...

— Пітер Кордес

У будь-якому разі, універсальна умова полягає в тому, що коли щось не вдається, ви шукаєте рядок помилки для коду помилки ( errno) і друкуєте це. (Використовуючи стандартну perrorфункцію бібліотеки C або еквівалент). Це один з рідкісних випадків, коли це не завжди достатньо підказки для користувача, щоб швидко знайти проблему, але в більшості випадків це працює дуже добре. (Особливо в поєднанні з straceтим, якщо є сумніви в тому, яка саме операція призвела до помилки.) Це не ідеально, але це може бути набагато гірше (пор. MS Windows, де в кращому випадку ви отримуєте код помилки для google.)

— Пітер Кордес

Просто грав з chattr +i, і зауважив , що rm foo(без -f) підказки: rm: remove write-protected regular file ‘foo’. Тому що faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX вимагає rmзапрошення за замовчуванням перед видаленням файлів, захищених від запису, і, тому він перевіряє в першу чергу. Таким чином, ви швидше отримали б велику підказку, якби не використовували rm -f. : / access(3)просить ядро перевірити дозволи, як ніби він справді відкривається для запису, тому він підбирає ACL та атрибути.

— Пітер Кордес