Отказано в доступе только для одного файла в каталоге от имени пользователя root в файловой системе ext3 под RAIDiator OS

У меня есть коробка ReadyNAS с именем «хранилище», которая, как я считаю, основана на Debian. Я могу ssh в него как root. Я пытаюсь перенастроить веб-сервер, но у меня проблема с правами доступа к файлам, которую я просто не понимаю. Я ничего не могу сделать /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?

— Нед64

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

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

@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нет возможности перечислять атрибуты. Я забыл, но, возможно, даже системный вызов для их запроса не является переносимым, поэтому, вероятно, было проще реализовать их в отдельной утилите.)

— Питер Кордес,

@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 и атрибуты.

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