 |
|
|
|
Лабораторная работа: исследуем inode. Часть 3. Завершение
Лабораторная работа: исследуем inode
Продолжение. Начало в [«СА» №7-8, 2017, URL: http://samag.ru/archive/article/3485] и [«СА», №9, 2017, URL: http://samag.ru/archive/article/3507], где были рассмотрены теоретические вопросы строения файловых систем (ФС) ext2-ext4, подготовка лабораторного стенда и первая часть практических заданий. Задания для самостоятельного выполнения Часть 2. Взаимодействие через утилиты ФС Пункт 5. По сравнению со стандартными командами более информативный вывод по inode можно получить, используя утилиты, осуществляющие прямой доступ к ФС: debugfs, lde (linux disk editor), dumpe2fs и др. Для экспериментов создадим новую ФС внутри файла и посмотрим, как выглядят inode в ней с точки зрения разных команд. Для того чтобы быть ближе к реальности, будем сравнивать то, что мы видим, с выводом стандартных команд взаимодействия с ФС, рассмотренных выше. Поскольку файловые системы ext2 и ext4 несколько отличаются, то файлов будет два: disk100ext2 и disk100ext4. Пункт 5.1. Создайте пустые файлы размером по 102 400 000 байт каждый и файловые системы внутри них: $ dd if=/dev/zero of=disk100ext2 bs=1024 count=100000 100000+0 записей считано 100000+0 записей написано скопировано 102400000 байт (102 MB), 0,202756 c, 505 MB/c $ dd if=/dev/zero of=disk100ext4 bs=1024 count=100000 ... $ mkfs -t ext2 -I 128 disk100ext2 ... $ mkfs -t ext4 -I 256 disk100ext4 ... Ключ «-I» задаёт размеры inode 128 и 256 байт, поскольку если размер не задать вручную, то для обеих ФС из файла mke2fs.conf будут взяты значения по умолчанию, как для ФС типа small – 128 байт, и в этом случае будут продемонстрированы улучшения, появившиеся в ext4 в сравнении с ext2.
Замечание. У ФС ext2-ext4 существует большое число всевозможных функциональных опций [1], влияющих на их работу и внутреннее устройство. Большая часть из них задаётся в момент создания ФС. Некоторые опции по умолчанию оказываются включенными, другие, наоборот, выключенными. Вручную задать или отключить опцию можно с помощью ключа «-O» команды mkfs, указав в качестве его параметра через запятую нужные значения. В случае если опция (возможность) должна быть отключена, перед ней ставится знак «^», например: $ mkfs -t ext2 -O ^ext_attr disk100ext2 До версии 1.43 дополнительные ключи «-O» игнорируются. Опция ext_attr указывает хранить расширенные атрибуты в inode. Таким образом, место хранения расширенных атрибутов в ФС, таких как ACL и SELinux (устанавливаемых через команды setfacl и chcon соответственно), напрямую зависит от её состояния. Пункт 5.2. Оцените параметры созданных файловых систем командами: $ dumpe2fs disk100ext2 ... $ dumpe2fs disk100ext4 Пункт 5.3. Ответьте на вопросы:
Пункт 5.4. Примонтируйте ФС, созданные внутри файлов disk100ext2 и disk100ext4, в директории /mnt/ext2 и /mnt/ext4 соответственно. $ sudo mount -o loop disk100ext2 /mnt/ext2 $ sudo mount -o loop disk100ext4 /mnt/ext4 Оцените получившийся результат из ОС, определите число занятых inode в ФС командами: $ mount ... /home/guest/disk100ext2 on /mnt/ext2 type ext2 (rw,loop=/dev/loop0) /home/guest/disk100ext4 on /mnt/ext4 type ext4 (rw,loop=/dev/loop1) $ df -i Filesystem Inodes IUsed IFree IUse% Mounted on … /home/guest/disk100ext2 25064 11 25053 1% /mnt/ext2 /home/guest/disk100ext4 24960 11 24949 1% /mnt/ext4 Пункт 5.5. Создайте файлы размером в 0 байт и несколько байт в обеих ФС. $ touch /mnt/ext2/file0 $ touch /mnt/ext4/file0 $ echo hello > /mnt/ext2/file1 $ echo hello > /mnt/ext4/file1 Замечание. Создание файлов, как и внесение изменений в них, при отсутствии нагрузки в системе должно происходить сразу. Однако, если при запуске последующих команд, осуществляющих прямой доступ к файлам disk100ext2 иdisk100ext4 с файловой системой внутри, запись в файловую систему почему-то «не прошла» (команды «не видят» последних изменений, которые должны быть), следует выполнить сброс буферов командой /bin/sync либо произвести отмонтирование файловой системы командами: $ sudo umount /mnt/ext2 $ sudo umount /mnt/ext4 при выполнении которых сброс произойдёт автоматически. Пункт 5.6. Исследуйте особенности хранения файлов в ФС с помощью команд ls и stat: $ ls -lisa /mnt/ext2 $ ls -lisa /mnt/ext4 $ stat /mnt/ext2/file0 $ stat /mnt/ext2/file1 $ stat /mnt/ext4/file0 $ stat /mnt/ext4/file1 Подумайте, почему по результатам вывода команды ls файл file0 нулевого размера в ФС ext2 занимает один блок с данными, а file1 – целых два? (Ответ на данный вопрос с пояснениями будет дан в третьей части.) Заметили ли вы, что точность хранимых меток времени отличается от типа ФС? В случае с ФС ext2 точность указывается до секунды, а далее пишутся нули «для совместимости» формата вывода, ФС ext4 хранит значение секунд сточностью до девяти знаков после запятой. Access: 2017-05-04 13:44:04.000000000 +0300 Access: 2017-05-04 13:44:08.024475329 +0300 Также заметьте, что в inode хранятся три метки времени, доступные пользовательским программам (на самом деле всего их четыре, подробнее об этом см. ниже):
Определите номера inode у исследуемых файлов. Напомним, что, поскольку номера с 0 по 11 зарезервированы ФС для разных целей [2], созданные файлы будут иметь номера 12 и 13. Также, объекты разных ФС могут иметь одинаковые номера, что вы могли успешно только что наблюдать, однако ОС не испытывает затруднений, работая с разными файлами в едином дереве VFS (Virtual File System), поскольку параметр Device, выводимый командой stat, у двух разных файлов с одинаковым именем file0 отличается. Пункт 5.7. Исследуйте те же самые файлы с помощью программы linux disk editor: $ lde -i 12 disk100ext2 Device "disk100ext2" is mounted, be careful User requested autodetect filesystem. Checking device ... Found ext2fs on device. ------------------------------------------------------------- INODE: 12 (0x0000000C) -rw-rw-r-- user user 0 Thu May 4 13:44:04 2017 TYPE: regular file LINKS: 1 MODEFLAGS.MODE: 010.0664 SIZE: 0 BLOCK COUNT: 2 UID: 00500 (user) GID: 00500 (user) ACCESS TIME: Thu May 4 13:44:04 2017 CREATION TIME: Thu May 4 13:44:04 2017 MODIFICATION TIME: Thu May 4 13:44:04 2017 DELETION TIME: Thu Jan 1 03:00:00 1970 DIRECT BLOCKS: INDIRECT BLOCK: DOUBLE INDIRECT BLOCK: TRIPLE INDIRECT BLOCK: $ lde -i 13 disk100ext2 ... $ lde -i 12 disk100ext4 $ lde -i 13 disk100ext4 Обратите внимание, что при выводе содержимого 12-го и 13-го inode ФС ext2, нигде не указаны имена файлов (file0 и file1 соответственно), то есть эта информация в них действительно не хранится. Также можно заметить и ранее упомянутую четвёртую метку времени – deletion time (время удаления). Отметьте время, установленное в ней: «начало эпохи UNIX» + «смещение часового пояса». Исследование inode после удаления файла мы произведём чуть позже. Посмотрите, сколько блоков занимает каждый из данных файлов. Обратите внимание, что у файла с именем file1 (inode=12 ФС=ext2) в параметре DIRECT BLOCKS содержится один номер блока, а в параметре BLOCK COUNT указано значение 4. Можете объяснить это расхождение? Замечание. Несмотря на то что первые 128 байт inode любых размеров одинаковы, можно отметить, что linux disk editor корректно не работает, когда размер inode в ФС больше 128 байт (в нашем случае для ФС ext4 он равен 256). Какследствие, вывод последних двух команд содержит «мусор». Программа lde давно не обновлялась, и скорее всего она неправильно определяет смещение для считывания нужных 128 байт. Если создать ФС ext4 с размером inode равным 128байт, то команда работает корректно. Помимо этого, у программы также возникают проблемы при отображении занимаемых блоков в ФС ext2. Для получения истинных результатов лучше использовать debugfs или «сырое» чтение с диска. Пункт 5.8. Исследуйте также с помощью команды lde содержимое соседних, заведомо не занятых inode на ФС ext2, например 14 и 15. $ lde -i 14 disk100ext2 Пункт 5.9. Поскольку программа lde является отдельной программой (не входящей в основной репозиторий ОС), да и к тому же не всегда корректно показывает реальное положение дел, исследуйте те же самые файлы (созданные в п.5.5) спомощью программы debugfs, её внутренними командами stat имя_файла и stat <X>, где X – номер inode. Выход осуществляется командой quit. $ debugfs disk100ext2 debugfs 1.41.12 (17-May-2010) debugfs: stat file0 Inode: 12 Type: regular Mode: 0664 Flags: 0x0 Generation: 703348796 Version: 0x00000000 User: 500 Group: 500 Size: 0 File ACL: 516 Directory ACL: 0 Links: 1 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5933e474 -- Thu May 4 13:44:04 2017 atime: 0x5933e474 -- Thu May 4 13:44:04 2017 mtime: 0x5933e474 -- Thu May 4 13:44:04 2017 BLOCKS: debugfs: stat <12> ... Как видно из параметра File ACL: 516, «нашлись ранее потерянные» блоки. Блок № 516 используется как расширение inode для хранения расширенных атрибутов (метаданных). Выполнив команду imap file0 или imap <12>, можно узнать, вкаком блоке находится inode, данная информация может быть полезна при «сыром» чтении данных из ФС, если вы не планируете самостоятельно выполнить вычисление смещений. debugfs: imap file0 Inode 12 is part of block group 0 located at block 292, offset 0x0180 debugfs – это замечательная утилита, на изучение которой стоит потратить время. С одной стороны, она имеет функционал «редактора диска», где требуется понимание строения ФС, с другой, для выполнения ручного восстановления данных (чтение содержимого удалённых файлов, исправление ошибок, возникших в результате сбоев) у неё есть много других полезных команд-аналогов, пришедших из bash'а: pwd, cd, rm, stat, cat. Схожесть имеется не только в названиях, но и в синтаксисе запуска, что сильно упрощает работу. Например, с помощью команды cat можно просматривать содержимое файлов по имени или по номеру inode. debugfs: cat <13> hello Повторите это действие. Выводить подобным образом двоичные файлы на консоль можно, но неудобно (из-за наличия в них непечатаемых и управляющих символов). При необходимости содержимое файла можно вывести не на консоль, а сохранить во внешний файл в реальной ФС. Выполните сохранение файла file1 (inode № 13) во внешний файл file1-out и просмотрите его. debugfs: dump <13> file1-out debugfs: quit $ cat file1-out hello Часть 3. «Сырое» чтение данных из ФС Если задаться вопросами, а что содержится в блоке данных № 516, указанном в параметре File ACL на предыдущем шаге, да и вообще можно ли «посмотреть» на метаданные любого файла побайтно в подробностях, то без сырого чтения данных из ФС не обойтись, поскольку если ставший в своё время классикой коммерческий Norton Disk Editor позволял делать это в отношении ФС FAT, то на сегодня найти аналогичную по удобству и функционалу GNU-программу для ФС ext2-4 проблематично. При наличии у пользователя соответствующих прав доступа на помощь приходят команды:
С таким набором фактически можно прочитать (просмотреть) и скопировать что угодно, откуда угодно и куда угодно, если речь идёт о файлах, ФС и физических дисках, доступных в системе как псевдофайлы блочных устройств. Зная изтеории необходимое смещение [2] и обладая достаточным количеством времени, можно работать с блоками размером в 1, 2 или n байт. Например, попытаемся просмотреть, как хранятся расширенные атрибуты у файлов, и выясним, что же находится в блоке данных № 516, указанном в inode файла file1. Пункт 6. Просмотрите содержимое файла file1 (в ФС ext2) с помощью команды od, выполнив нижеследующие шаги. Пункт 6.1. Попытаться определить смещение inode № 13 можно и глядя на рис. 1, но задача эта непростая. Во-первых, нужно знать размеры отображённых там элементов. Во-вторых, резервные блоки были упомянуты вскользь, они неотображены на рисунке и ничего не было сказано про их количество. В третьих, задача расчёта смещения inode не является целью данной работы. Поэтому проще воспользоваться информацией из вывода команды dumpe2fs – для широкого взгляда на ФС и debugfs – для рассмотрения интересующего нас места в более мелком масштабе. $ dumpe2fs disk100ext2 … Group 0: (Blocks 1-8192) Primary superblock at 1, Group descriptors at 2-2 Reserved GDT blocks at 3-258 Block bitmap at 259 (+258), Inode bitmap at 260 (+259) Inode table at 261-501 (+260) 7675 free blocks, 1915 free inodes, 2 directories Free blocks: 518-8192 Free inodes: 14-1928 … debugfs: imap file1 Inode 13 is part of block group 0 located at block 262, offset 0x0200
Рисунок 1. Структура файловой системы ext2 Считаем inode и определим, какой дополнительный блок используется для хранения расширенных прав (списков доступа (ACL), а также какие блоки хранят данные файла. Предварительно преобразуем 0x020016 = 51210 и вычислим 1024 * 262 + 512 = 268800. $ od -t x1 disk100ext2 -j 268800 -A d -N 128 0268800 b4 81 f4 01 06 00 00 00 87 03 35 59 87 03 35 59 0268816 87 03 35 59 00 00 00 00 f4 01 01 00 04 00 00 00 0268832 00 00 00 00 00 00 00 00 05 02 00 00 00 00 00 00 0268848 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0268896 00 00 00 00 17 5a 1e 2b 04 02 00 00 00 00 00 00 0268912 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Рисунок 2. Структура ссылок на номера блоков в inode В [2] находим таблицу, описывающую более точное строение inode, нежели представлено на рис. 2, откуда определяем смещение для получения байтов с номером блока, где хранятся расширенные атрибуты.
0x6816=10410, данные типа __le32 занимают 4 байта. Все адреса в нашем примере 32-битные, поэтому старших 32 битов от адреса просто нет (считаем равными нулю). Смещение будет 268800 + 104 = 268904. Находим эти байты в выводе выше и переводим из формата little endian unsigned int в десятичный вид либо выведем только эти байты, а также изменим формат их отображения. $ od -t x1 disk100ext2 -j 268904 -A d -N 4 0268904 04 02 00 00 $ od -t d disk100ext2 -j 268904 -A d -N 4 0268904 516 Итого, получился номер блока 516 – тот же самый номер, что выводила команда stat утилиты debugfs. Смещение блока будет 516 * 1024 = 528384. Читаем содержимое блока, пытаясь при этом отобразить данные в виде ASCII-символов. $ od -t ax1 disk100ext2 -j 528384 -A d -N 1024 0528384 00 00 02 ea 02 00 00 00 01 00 00 00 cf 47 b1 6d 0528400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0528416 bel ack ` etx nul nul nul nul sp nul nul nul O G 1 m 07 06 e0 03 00 00 00 00 20 00 00 00 cf 47 b1 6d 0528432 s e l i n u x nul nul nul nul nul nul nul nul nul 73 65 6c 69 6e 75 78 00 00 00 00 00 00 00 00 00 0528448 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0529376 u n c o n f i n e d _ u : o b j 75 6e 63 6f 6e 66 69 6e 65 64 5f 75 3a 6f 62 6a 0529392 e c t _ r : f i l e _ t : s 0 nul 65 63 74 5f 72 3a 66 69 6c 65 5f 74 3a 73 30 00 В первых четырёх байтах видно «магическое число» 0xEA020000 [2], хранимое в формате little endian, которое ставится в начале блока как отличительный идентификатор, сообщающий о том, что далее хранятся расширенные атрибуты. Впоследних строчках (выделено цветом) явно просматривается типичный контекст безопасности SELinux. В подтверждение догадки проверим, какой контекст был выставлен у файла /mnt/ext2/file1. $ ls -Z /mnt/ext2/file1 -rw-rw-r--. user user unconfined_u:object_r:file_t:s0 /mnt/ext2/file1 Замечание. Первоначально блок расширенных атрибутов использовался для хранения как контекстов SElinux, так и списков контроля доступа (ACL). Поэтому если просмотреть содержимое блока, а затем у файла поменять записи списка контроля доступа (ACL-записи), то после, при повторном просмотре, можно будет заметить изменения. Например (про условии, что ACL-блок сохранит свой номер и, как следствие, смещение): $ getfacl /mnt/ext2/file1 $ od -t ax1 disk100ext2 -j 528384 -A d -N 1024 … $ setfacl -m u:root:r-- /mnt/ext2/file1 $ getfacl /mnt/ext2/file1 $ od -t ax1 disk100ext2 -j 528384 -A d -N 1024 … Единственное – наглядности, как с контекстом SELinux, не получится, поскольку данные не хранятся в виде текста из ASCII-символов. Также во избежание ошибки setfacl: /mnt/ext2/file1: Неподдерживаемая операция ФС должна быть примонтирована с опциями user_xattr и acl, например: $ sudo /bin/mount -o loop,user_xattr,acl disk100ext2 /mnt/ext2 По умолчанию и, соответственно, при монтировании ФС в п. 5.4 эти опции отключены. При просмотре списка файлов в директории командой ls -l, после обычных прав доступа у файлов, имеющих ACL-записи, будет виден знак «+». $ ls -l /mnt/ext2/file1 -rw-rw-r--+ 1 user user 6 May 4 13:44 /mnt/ext2/file1 Замечание 2. Также к расширенным атрибутам относятся и способности (см. man 7 capabilities). Вот пример установки и считывания способностей: $ sudo setcap cap_sys_admin+ep /mnt/ext2/file1 $ getcap /mnt/ext2/file1 (Данный пример «включает» способности, использующиеся для предоставления разрешения перехвата данных с сетевых интерфейсов программам, запускаемым не от суперпользователя. В данный момент они бессмысленны, поскольку file1 – не программа.) После установки какой-либо возможности при просмотре содержимого блока расширенных атрибутов в виде ASCII-текста вы сможете увидеть слово «capability», а разобрав соседние двоичные значения по формату, можно выяснить детали. Пункт 6.2. Определим номер блока с данными у того же файла file1 и прочитаем его. Из рис. 2 видно, что адрес нулевого блока с данными будет храниться по смещению 40 байт от начала inode, то есть смещение от начала диска составит значение, полученное на шаге 6.1, – 268800 + 40 = 268840. Считываем 4 байта и переводим их должным образом в десятичный вид. $ od -t x1 disk100ext2 -j 268840 -A d -N 4 0268840 05 02 00 00 $ od -t d disk100ext2 -j 268840 -A d -N 4 0268840 517 Получился номер блока с данными 517 – тот же самый номер, что выводила команда stat утилиты debugfs. Смещение блока будет 517 * 1024 = 529408. Читаем содержимое блока (например, первые 10 символов), отображая данные в виде ASCII-символов. $ od -t a disk100ext2 -j 529408 -A d -N 1024 0529408 h e l l o nl nul nul nul ... Пункт 6.3. Исследуйте, какое значение хранится в бай-тах, отведённых для адреса первого блока с данными. Из рис. 2 видно, что это значение следует сразу же за байтами, отведёнными для адреса первого блока с данными. То есть ксмещению можно просто добавить 4. Также, если интересно, можно посчитать адреса смещения соседних блоков и «заглянуть» в них, задавшись вопросом: пустые они или нет? Конечно, наличие нулевых символов по всему блоку ни о чём не говорит и правильным будет определять, занят блок или нет, обратившись к битовой карте блоков, но исследование её выходит за рамки темы данной работы. Пункт 7. Вычислите момент (два соседних значения размера файла), когда будет переход к хранению информации с использованием косвенной адресации. Обратившись к рис. 3, можно увидеть, что это произойдёт, когда будет израсходован объём 12 блоков данных, адресуемых 12 адресами прямой адресации. Пункт 7.1. Используя команды и знания, применявшиеся ранее, проверьте на практике полученное в п. 7 значение. Пункт 8. Для ФС с блоком данных размером 1024 байта выведите формулу и произведите теоретический расчёт размера файла, начиная с которого будет использоваться двойная косвенная адресация. Пункт 8.1. Повторите расчёт для ФС с блоком данных размером 4096 байт. Пункт 9. Просмотрите дату и время, а затем удалите файл /mnt/ext2/file1. $ date -R Thu, 04 May 2017 14:51:32 +0300 $ rm /mnt/ext2/file1 Поскольку в обычных условиях данные inode после удаления файла не стираются, то по ранее определённому его номеру и вычисленному на его основе смещению произведите просмотр содержимого inode в части deletion time. Время хранится в формате __le32 в секундах с начала эпохи UNIX по смещению 0x14 (подробнее об этом и других полях см. [2]). Соответствует время удаления файла тому, что было записано в его inode, когда файл существовал? Пункт 10. Повторите пункты заданий частей 2 и 3 для ФС ext4, оцените, что изменилось. Пункт 11. Вернём систему к первоначальному состоянию. Исходя из того, что по ходу выполнения заданий все файлы и директории создавались в директории ~/dir1, удалим её со всем содержимым. $ rm -rf ~/dir1 Если вы создавали объекты ФС в других местах – удалите их. Будет ещё один повод повторно пробежаться по выполненным заданиям и уяснить, что же вы проделали и какие объекты создавали. Стереть историю команд в bash можно командой: $ history -c При этом будут удалены все команды из истории, в том числе и те, что ранее существовали в файле ~/bash_history до проведения данной работы. Ответ на вопрос, заданный в п.5.6: пустой файл по результатам вывода программы stat занимает два блока на диске, потому как данные отображаются порциями по 512, а при размере блока 1024 порций будет две и отобразиться число 2, а не1. Вторая часть вопроса: не важно, один блок или два, почему файл занимает не ноль? Дело в том, что в системе по умолчанию «включен SELinux», который автоматически добавляет файловым объектам контекст безопасности (вы егомогли увидеть в п. 6.1). Поскольку в ФС ext2 мы специально задали inode размером 128 байт при её создании, то хранить его негде, кроме как в отдельном блоке. Создай мы ФС с inode размером 256 или больше байт, данные скорее всего уместились бы в нём и дополнительный блок не потребовался бы. Можете это проверить. Также и при размере inode в 128 байт возможно не использовать дополнительный блок. Для этого надо в корне отключить selinux (чтобы команда getenforce выводила Disabled). Сделать это можно тремя путями: либо установить в файле /etc/selinux/config параметр SELINUX=disabled и перезагрузить систему, либо передать ядру через загрузчик GRUB параметр selinux=0, либо перекомпилировать ядро без поддержки SELinux и загрузиться с него. У старых файлов контекст безопасности никуда не исчезнет, а создаваемые новые будут без него, и тогда файл размера 0 будет занимать 0 блоков на диске. Заключение В результате выполнения заданий работы и подготовки к ним вы освежили в памяти устройство отдельных частей ФС ext2-ext4 и имели возможность более близко познакомиться с такой её частью, как inode, если не сказать иначе – «взглянуть внутрь». В ходе выполнения практических занятий вы должны были глубже понять роль индексного дескриптора с точки зрения организации хранения файлов и связанной с ними информации (метаданных), также вы имели возможность оценить различные количественные параметры за счёт использования стандартных программ и «сырого чтения», научились взаимодействовать с файлами, имеющими «необычные» символы в имени. Вы должны были «увидеть», где и как хранятся расширенные атрибуты файлов, а также что значит хранение данных (например, коротких ссылок) внутри inode. Возможно, вы открыли для себя новые утилиты и команды. Полученные знания вам, несомненно, пригодятся, когда вы столкнётесь с проблемой восстановления целостности ФС и «потерянной информации» и в ряде других ситуаций.
|
ПАВЕЛ ЗАКЛЯКОВ, ИТ-специалист
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
