Может ли файл быть извлечен его inode?

Я выполнил следующие команды в указанном порядке:

$ln ab $ls -iab 523669 a 523669 b $rm -fa $ls -ib 523669 b 

Я пришел к выводу из этого теста, что команда rm фактически удаляет только имя файла ( a в этом тесте) вместо файла, так как inode все еще существует и может быть получен через другое имя файла ( b ).

Мой вопрос в том, что если файл жестко связан только с одним именем файла, когда rm выполняется в файл, полностью ли удаляется реальный файл (т. Е. Индексный дескриптор)? А если нет, можно ли извлекать файл inode без имени файла и только через индексный дескриптор?

4 Solutions collect form web for “Может ли файл быть извлечен его inode?”

Если вы попытаетесь открыть файл с помощью inode, это обходит любой обход каталога. Обход каталога необходим для определения разрешений файла и каталогов, ведущих к нему. Без обхода каталога ядро ​​не имеет способа определить, разрешен ли вызывающему процессу доступ к файлу.

Был предложен патч для ядра Linux, чтобы создать ссылку на файл из файлового дескриптора . Он был отвергнут, поскольку осуществление этого безопасного было бы чрезвычайно тяжело .

В Linux (и, возможно, в других вариантах unix по той же причине) вы не можете создать ссылку на удаленный файл, поэтому, если файл больше не имеет имени, вы не можете повторно добавить его .¹ Вы можете открыть удаленный файл файл, открыв магические ссылки под /proc/$pid/fd/ .

Если файл больше не имеет ссылки и больше не открыт, он больше не существует, и пространство, ранее использовавшееся его данными, может быть восстановлено в любое время.

¹ Вы можете сделать это, спрятав байты непосредственно в файловой системе зависимым от файловой системы способом, например, с debugfs для ext2 / ext3 / ext4. Для этого требуется доступ к устройству, на котором монтируется файловая система (т. Е. Обычно это может быть только root). Однако, хотя debugfs могут обращаться к файлу с помощью inode, это не помогает, если файл будет удален: файл будет действительно удален, если приложение закроет его, а запуск debugfs в режиме чтения-записи на смонтированной файловой системе – это рецепт для катастрофа.

В Linux, debugfs , отладчик файловой системы ext2 / ext3 / ext4 для интерактивного ext2 обеспечивает команду ln которая может принимать номер inode как filespec и создавать новую жесткую ссылку на соответствующий файл. На практике, однако, для этого требуется, чтобы несвязанный файл оставался открытым процессом , поддерживая дескриптор открытого файла в /proc/[pid]/fd/[n] . Попытка этого удалить в удаленном файле, скорее всего, приведет к повреждению файловой системы.

Это связано с тем, что для обеспечения того, чтобы ext3 (и в ext ext4) мог безопасно возобновить разблокировку после сбоя, он фактически нулевым образом выводит указатели блоков в индексном дескрипторе , тогда как ext2 просто отмечает эти блоки как неиспользуемые в растровых изображениях блоков и отмечает inode как «удаленный» и оставляет только указатели блоков. Тем не менее, поскольку файловая система должна быть смонтирована для чтения и записи для создания жесткой ссылки, блоки, зарезервированные для удаленного файла, возможно, уже были перераспределены.

До версии 2.6.39 ядра раньше использовалась опция ln -L|--logical представленная в GNU coreutils v8.0 , для восстановления несвязанного файла через дескриптор открытого файла в /proc/[pid]/fd/[n] если оба несвязанных файла и новая жесткая ссылка находятся в файловой системе tmpfs . С тех пор эта возможность была отключена из-за того, что, как указал Жиль , соображения безопасности, связанные с возможностью создания жестких ссылок непосредственно из файлового дескриптора.

Команды «ln» и «rm» работали именно так в каждой файловой системе UNIX с начала 1970-х годов. Mac OSX, BSD и Linux наследуют этот оригинальный дизайн.

Сам по себе UNIX-файл не имеет имени, только номер или inode . Но вы можете получить доступ к нему только через запись в специальном файле «directory», который связывает имя с указанным inum; вы не можете указать вход inum напрямую.

Каталог сам по себе является файлом, поэтому вы также должны обращаться к нему через (другую) директорию и т. Д. Через серию имен каталогов, разделенных прямыми косыми чертами (/), известными как «имя пути». Путь начинается в «текущем рабочем каталоге» процесса, если имя не начинается с «/», и в этом случае он начинается с корневого каталога файловой системы. Например, если имя пути не содержит символов «/», то ожидается, что это будет запись в текущем каталоге.

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

Хотя в каталогах есть номера inode, большинство файловых систем запрещают жесткие ссылки на них; они могут отображаться только в одном другом каталоге. (Одним из необычных исключений является файловая система Mac OSX HFS +, это позволяет работать с резервными копиями Time Machine.) Вы все равно можете создавать «мягкие ссылки» на каталоги (или любой другой файл). Мягкая ссылка похожа на запись каталога, за исключением того, что она содержит другое имя пути, а не inum.

Каждый UNIX-файл имеет права владельца, группы и доступа. Необходимо, но недостаточно, чтобы они разрешили вам открыть файл; вы также должны иметь хотя бы разрешение на выполнение для каждого каталога в имени пути, которое вы используете для ссылки на него. Вот почему нет стандартного способа открыть UNIX-файл по его номеру inode; что обойдет важный, широко используемый механизм безопасности.

Но это не объясняет, почему не может быть стандартного способа для root (привилегированного) пользователя открывать файл по номеру inode, поскольку проверка разрешений в любом случае обходит. Это было бы очень полезно для некоторых функций управления системой, таких как резервные копии. Насколько мне известно, такие механизмы существуют, но все они специфичны для файловой системы; нет общего способа сделать это для любой файловой системы UNIX.

Вопрос может быть принят теоретически (что может быть достигнуто с помощью debugfs ) или прагматично (аварийная ситуация). В последнем случае я предполагаю, что цель – сохранить день и восстановить содержимое файла, возможно, в срочном порядке (так я приземлился по этому вопросу, поэтому считаю, что он по-прежнему актуальен и полезен).

Поскольку API ядра не существует, debugfs не следует запускать в живой файловой системе, поскольку он напрямую управляет структурой FS. Поэтому, чтобы сделать это вживую, вы должны получить другое имя файла. Предполагая, что файл по-прежнему открыт каким-то процессом (любым процессом), можно найти для удобных файловых дескрипторов в /proc :

 $ lsof -F pf "$PWD/a" | sed 's/^p//' # find pid and file descriptor number of any process having the file open $ pid=1234 $ ls -l /proc/$pid/fd/* | grep "$PWD/a" # find file descriptor number $ fd=42 $ cat /proc/$pid/fd/$fd > "$PWD/a.restored" # read contents to a new filename 

Советы:

  • если у вас есть сомнения относительно правильного fd, вы можете запускать такие команды, как file на нем
  • если в файл записывается процесс, обязательно остановите этот процесс как можно скорее или вы не получите последние данные. Трюк (непроверенный) может заключаться в том, чтобы открыть файл, считанный только через fd, с каким-либо другим процессом (попробуйте tail -f > /proc/$pid/fd/$fd > /dev/null , выйдите из процесса записи, чтобы он выходил чисто, и использовать fd нового процесса.
  • Удалите все * .mp4 и * .zip, но некоторые файлы
  • Как удалить файлы, которые не заканчиваются на «.c»?
  • Удаление всех файлов в папке, кроме файлов X, Y и Z
  • Не удается удалить файлы даже с помощью root, lsattr также не отвечает
  • Что такое обычный файл?
  • Как удалить скрытую папку?
  • Я случайно вышел из vim с: x! ~, И теперь моя ~ появляется по другому пути
  • Как найти удаляемые файлы, которые были удалены?
  • Как рекурсивно удалить все файлы и папки, кроме нескольких определенных папок?
  • Не удалось создать файл rm: превышена дисковая квота
  • Обходной путь для отсутствующей опции rm -I на OSX?
  • Linux и Unix - лучшая ОС в мире.