Free blocks, 2112 free inodes, 481 used directories

Free blocks, 2247 free inodes, 651 used directories

Free blocks, 2245 free inodes, 521 used directories

Free blocks, 2153 free inodes, 343 used directories

********************************************************************

Group 51: block bitmap at 1671168, inode bitmap at 1671169, inode table at 1671170

Group 52: block bitmap at 1703936, inode bitmap at 1703937, inode table at 1703938

Group 53: block bitmap at 1736704, inode bitmap at 1736705, inode table at 1736706

Рис. 4.6. Окончание

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

Битовая карта блоков (block bitmap) – это структура, в которой каждому логическому блоку соответствует один бит (рис. 4.7). Порядковый номер бита соответствует порядковому номеру блока. Если бит равен 1, то блок занят каким-либо файлом, если равен 0 – свободен. Эта карта служит для поиска свободных блоков в тех случаях, когда надо выделить место под файл. Вот как выглядит фрагмент 2-го логического блока. Байты FF в двоичном виде – это 1111 1111b (все блоки заняты). Со смещения 24CCh начинаются свободные блоки. Просматривая block bitmap, можно увидеть несколько чередующихся занятых и свободных полей блоков. Поскольку блоки идут в линейном порядке, это говорит о том, что система распределяет хранимую информацию по всему дисковому пространству.

Наличие в сплошном массиве байтов, отличных от FF, указывает на то, что в файловой системе присутствуют свободные блоки, ранее принадлежавшие каким-то файлам. При детальном изучении битовой карты можно сказать, сколько блоков занимал удаленный файл, и назвать порядковые номера этих блоков. К сожалению, эту работу простой не назовешь, но автоматическое восстановление удаленных файлов часто приводит к грубым просчетам и необратимой порче данных. О том, какие команды следует использовать для вывода информации о свободных блоках, будет сказано ниже.

0x00002460 FF FF FF FF FF FF FF FF: 3F FC 3F F0 FF FF FF FF........?.?.....

0x00002470 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00002480 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00002490 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x000024A0 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x000024B0 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x000024C0 FF FF FF FF FF FF FF FF: FF FF FF 0F 00 00 00 00................

0x000024D0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x000024E0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x000024F0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x00002500 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x00002510 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x00002520 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x00002530 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

Рис. 4.7. Фрагмент битовой карты блоков

Битовая карта индексных дескрипторов имеет аналогичную структуру, но иную гранулярность: один бит соответствует 128-байтному фрагменту в таблице inode (в ext4fs размер inode увеличен до 256 байтов). Фрагмент битовой карты индексных дескрипторов приведен на рис. 4.8.

0x000037B0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x000037C0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x000037D0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x000037E0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x000037F0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x00003800 00 00 00 00 FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00003810 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00003820 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00003830 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00003840 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

0x00003850 FF FF FF FF FF FF FF FF: FF FF FF FF FF FF FF FF................

Рис. 4.8. Фрагмент битовой карты индексных дескрипторов

В приведенном фрагменте наблюдается иной порядок, чем в битовой карте блоков: вначале идут свободные индексные дескрипторы, затем занятые. По-видимому, в данной группе блоков свободные дескрипторы были зарезервированы в пространстве, выделенном какому-то каталогу.

Следующая область в структуре группы блоков служит для хранения таблицы индексных дескрипторов файлов. Каждому файлу на диске соответствует один индексный дескриптор файла, который идентифицируется своим порядковым номером – индексом файла. Индексные дескрипторы файлов данной группы блоков хранятся в логических блоках, расположенных следом за битовой картой индексных дескрипторов. При стандартном размере inode в 128 байтов один 4-килобайтный логический блок вмещает 32 дескриптора. Таким образом, 16416 индексных дескрипторов, приходящихся на одну группу, займут подряд 513 логических блоков. Такой расчет справедлив для файловой системы ext2fs, однако если на логическом разделе смонтирована файловая система ext3fs, информация, выводимая отладчиком debugfs, может оказаться неверна. В журнализируемой файловой системе ext3fs между битовой картой inode и таблицей индексных дескрипторов обычно размещается журнал транзакций, под который обычно отводится 8192 блока, или 32768 Мб. В таком случае в первой группе блоков таблица индексных дескрипторов будет начинаться не с 4-го, а с 8195-го логического блока. Правильные адреса в любом случае находятся в описателе группы блоков.

Индексный дескриптор файла в ext2fs и ext3fs имеет объем 128 байтов и структуру, изображенную в табл. 4.3.

Нетрудно заметить, что некоторые поля фрагментированы. Проектировщиков первых систем часто упрекают в непредусмотрительности, однако человеку действительно трудно увидеть будущее и предусмотреть грядущие потребности. Так, 4-байтовые поля, содержащие временные отметки файлов, переполнятся в январе 2038 года. Возможно, авторы первых систем UNIX рассчитывали на продолжительность только своего века и никак не предполагали, что их творение прослужит так долго.

Таблица 4.3

Размер поля, байт	Смещение, байт	Описание
		Тип файла и права доступа к нему
	2h	Идентификатор владельца файла UID (младшие разряды)
	4h	Размер файла в байтах (младшие разряды)
	8h	Время последнего обращения к файлу
	Ch	Время создания файла.
	10h	Время последней модификации файла
	14h	Время удаления файла
	18h	Идентификатор группы GID (младшие разряды)
	1Ah	Счетчик числа связей («жестких» ссылок на файл)
	1Ch	Число секторов по 512 байт, занимаемых файлом
	20h	Флаги файла
	24h	Зарезервировано для ОС
15х4	28h	Указатели на блоки, в которых содержатся данные файла
	64h	Версия файла (для NFS)
	68h	Блок расширенных атрибутов (ACL файла)
	6Ch	ACL каталога или старшие разряды размера файла
	70h	Адрес фрагмента
	74h	Номер фрагмента
	75h	Размер фрагмента
	76h	Не используется
	78h	Идентификатор владельца файла UID (старшие разряды)
	7Ah	Идентификатор группы GID (старшие разряды)
	7Ch	Не используется

В файловой системе ext4fs размер индексного дескриптора увеличен до 256 байтов. Конкретный размер inode в шестнадцатеричном виде хранится в двухбайтовом поле суперблока по смещению 58h. Но как разумно распорядиться дополнительным пространством, обеспечив при этом совместимость с прежними версиями ФС, разработчики еще не решили.

Таблицу индексных дескрипторов можно вывести поблочно и поэлементно с помощью конвейера команд:

dd if=/dev/hda7 bs=4096 skip=4 count=1|dd bs=128 skip=1 count=1|xxd

Задавая номер логического блока и смещение от его начала, мы можем вывести для просмотра или скопировать в файл любой нужный нам дескриптор. Вышеприведенной командой на экран выводится дамп 2-го индексного дескриптора, содержащего метаданные корневого каталога. Некоторое неудобство заключается в том, что в описателе группы адреса являются шестнадцатеричными числами, а программа dd «понимает» только десятичные числа.

Произвольно взятый фрагмент из двух индексных дескрипторов представлен для анализа на рис. 4.9. Размер каждого из inode в данном примере составляет 128 байтов, следовательно, интервал между ними – 80h.

0x02003A00 ED 4100 0000 10 00 00: DC 09 69 400C 96 59 40. A........i..Y@

0x02003A10 0C 96 59 4000 00 00 00: 00 0002 0008 00 00 00..Y@............

0x02003A20 00 00 00 00 00 00 00 00: 1B 82 06 00 00 00 00 00................

0x02003A30 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x02003A40 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x02003A50 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x02003A60 00 00 00 00 9C 79 17 E5: 00 00 00 00 00 00 00 00.....y..........

0x02003A70 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x02003A80 A4 81 00 00 37 00 00 00: 1A 96 59 40 0C 96 59 [email protected]@

0x02003A90 12 6E A8 3E 00 00 00 00: 00 00 01 00 08 00 00 00.n.>............

0x02003AA0 00 00 00 00 00 00 00 00: 1C 82 06 00 00 00 00 00................

0x02003AB0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x02003AC0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x02003AD0 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

Рис. 4.9. Фрагмент таблицы индексных дескрипторов

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

Произведем разбор байтов в представленных фрагментах. Первые два байта несут очень важную информацию о типе файла и правах доступа к нему. Как уже было отмечено выше, в ОС Linux может быть 7 типов файлов. Информация о типе файла расположена в старшем нибле (октете) старшего байта (табл. 4.4).

Таблица 4.4.

Тип файла	Обозначение типа файла в листинге, выводимом командой ls -l	Шестнадцате-ричный символ
Обычный файл	-
Каталог	d
Символическая ссылка	l	С
Сокет	s	A
Именованный канал	p
Файл блочного устройства	b
Файл символьного устройства	c

Права доступа к файлу отображаются 12 двоичными разрядами, состоящими из 4 полей по 3 разряда в каждом. Для удобства интерпретации данных шестнадцатеричные числа следует преобразовать в двоичную форму, а затем биты сгруппировать удобным образом.

Двоичные разряды старшей тройки обозначают дополнительные (эффективные) права на файл. Они условно обозначаются: SUID – бит, позволяющий любому запускать исполняемый файл с правами его владельца (действует лишь в отношении бинарных исполняемых файлов), SGID – очень редко используемый бит, позволяющий запустить процесс с правами группы владельца, Sticky bit – «флажок», не позволяющий пользователю удалять из каталога файлы, ему не принадлежащие.

Все оставшиеся тройки интерпретируются одинаково: левый бит – право на чтение, средний – на запись, правый – на исполнение. Левая тройка – права владельца, средняя тройка – права пользователей из его группы, правая тройка – права для остальных зарегистрированных пользователей.

Так, в первых двух байтах первого inode на рис. 4.9 записано шестнадцатеричное число 41 EDh. По цифре 4 в старшем разряде мы определяем, что перед нами – каталог. Оставшуюся часть числа преобразуем в двоичную форму, для наглядности группируя биты по три разряда:

1EDh = 0001 1110 1101b = 000 111 101 101

При определенном навыке читать права доступа можно и без подобного преобразования. Читаем:

· эффективных прав доступа к каталогу не установлено: 000,

· владелец имеет на свой каталог полные права: 111 = rwx,

· члены группы владельца имеют права на чтение и исполнение: 101 = r-x,

· все остальные зарегистрированные пользователи также имеют права на чтение и исполнение (что вполне естественно для каталога общего назначения).

Следующее слово является младшими разрядами идентификатора владельца файла ­Owner UID. На это поле выделено два байта, чего с избытком хватает для регистрации любого разумного числа пользователей. Два старших байта UID, размещенные в другой ячейке, обычно пустуют. Только администратор системы имеет нулевой идентификатор. По числу 00 00h убеждаемся, что владельцем каталога именно он и является.

Следующее двойное слово содержит младшие разряды размера файла в байтах. Старшие 4 байта, как видно из табл. 4.3, размещены в другой ячейке inode и обычно пустуют. 00 00 10 00h = 4096 байтов – обычный при данном размере логического блока объем каталога.

Четыре поля по 4 байта в каждом отображают временные отметки файла:

· последнего обращения,

· последней записи в индексный дескриптор,

· последней модификации данных в файле,

· удаления.

Все поля, содержащие временные отметки, содержат число секунд, прошедших с полуночи 1 января 1970 года (как выражаются почитатели UNIX – с начала Эпохи). Чтобы узнать это время, нужно вначале преобразовать число в десятичное, затем пересчитать секунды в дату и время. Утилиты для преобразования в обычное представление даты и времени в штатной инсталляции операционной системы нет, но зато имеется системная функция, которую можно вызвать из исполняемого файла или сценария, написанного на языке Perl.

Для отображения различных сведений о файле, включая его временные отметки, предназначена утилита stat. Точнее, она выдает сведения об еще не удаленных файлах, поэтому времени логического удаления файла она не показывает:

stat –c %x,%X abc – время последнего доступа,

stat –c %y,%Y abc – время последней модификации,

stat –c %z,%Z abc – время создания.

Приведенные команды выводят временные отметки файла abc из текущего каталога вначале в секундах от начала «Эпохи», затем в обычном формате. Команда в коротком формате stat abc выведет всю информацию о файле abc, но временные отметки будут представлены в обычном виде.

Разработчики системы, предусмотрев в индексном дескрипторе файла время его удаления, предполагали, что удаление файла не сопровождается физическим стиранием данных и после удаления файла его inode какое-то время будет существовать. Это предположение справедливо только в отношении файловой системы ext2fs. Как будет показано ниже, удаление файла в этой ФС действительно не сопровождается ни удалением inode, ни стиранием информации в блоках, выделенных файлу. Удаление файла в ext2fs – это лишь стирание его последнего имени («жесткой» ссылки) в каталоге. Странная дата удаления всех «живых» файлов – 1 января 1970 года – указывает на то, что счетчик секунд в этом поле равен нулю.

По порядку расшифровываем следующие поля. Идентификатор группы имеет значение, равное 00 00h, – это группа root (суперпользователя). На каталог имеется две жесткие ссылки (00 02h), что означает отсутствие внутри него подкаталогов. Каталог занимает 8 секторов по 512 байтов на диске, что соответствует размеру одного блока в 4096 байтов. Дополнительные права доступа (флаги) не устанавливались. Единственный логический блок, в котором хранится таблица соответствия между именами файлов данного каталога и их индексными дескрипторами, имеет порядковый номер 00 06 82 1Bh. В этом блоке можно прочитать имена и inode файлов этого каталога.

Аналогично определим параметры другого файла, приведенные на рис. 4.9. Первая шестнадцатеричная цифра слова 81 А4h указывает на то,

что это обычный файл, а двоичная комбинация

1А 4h = 0001 1010 0100b = 000 110 100 100

дает всю необходимую информацию о правах доступа:

· эффективные права доступа не установлены,

· владелец файла имеет право на чтение и запись,

· члены его группы и остальные пользователи имеют право на чтение,

Владельцем файла является root – администратор. Файл имеет размер 37h = 55 байтов и так далее. По информации, содержащейся в inode, уже нетрудно найти и идентифицировать файл. Например, можно попытаться обнаружить файл по совокупности характеристик: типу, объему, правам доступа, временным отметкам:

find / -type f –a –size 12320c –a –perm 0644 –ctime....

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

find / -inum 123456,

где 123456 – порядковый номер inode.

В более удобной для анализа форме вывести информацию об индексном дескрипторе можно, воспользовавшись для этого утилитой lde (linux disk editor). К сожалению, дисковый редактор неправильно отображает 256-байтные inode современных ФС. На рис. 4.10 приведен пример вывода результатов этой команды для индексного дескриптора каталога /bin.

lde –i 131329 /dev/hda5

INODE: 131329 (0x00020101)

drwxr-xr-x 0 0 4096 Thu Mar 18 17:42:58 2004

TYPE: directory

LINKS: 2

MODEFLAGS.MODE: 004.0755

SIZE: 4096

BLOCK COUNT: 8

UID: 00000

GID: 00000

ACCESS TIME: Tue Mar 30 11:46:37 2004

CREATION TIME: Thu Mar 18 17:42:58 2004

MODIFICATION TIME: Thu Mar 18 17:42:58 2004

DELETION TIME: Thu Jan 1 00:00:00 1970

DIRECT BLOCKS: 0x00040203

INDIRECT BLOCK:

DOUBLE INDIRECT BLOCK:

TRIPLE INDIRECT BLOCK:

Рис. 4.10. Информация об inode каталога /bin, выведенная редактором lde

Ниже для сравнения приведена запись об этом же каталоге, выведенная командой ls –ali /bin. Утилита ls для вывода этой информации также обращается к таблице индексных дескрипторов.

131329 drwxr-xr-x 2 root root 4096 Мар 18 17:42

Еще раз обратим внимание на временные отметки файла на рис. 4.10. Время удаления файла, датируемое 1970 годом, – не временной парадокс, а единая точка отсчета всех 4 временных отметок. Если она не указывает правдоподобное время, то файл еще не удалялся.

Система адресации данных – это одна из самых существенных составных частей файловой системы. Всего в inode для целей адресации зарезервировано 15 полей по 4 байта. Номера первых 12 блоков хранятся непосредственно в inode; их еще иногда называют блоками с прямой адресацией (direct blocks). При размере логического блока 4 Кб таким образом можно создавать файлы размером до 4 х 12 = 48 Кб.

При большем объеме файла используется нелинейная система адресации данных. Очередное поле содержит адрес (номер) блока, в котором хранятся номера еще 256 блоков данных. Его называют блоком косвенной адресации (indirect block).

Если файл все же не помещается в пространство 256 х 4 + 48 = 1072 Кб, очередное поле inode указывает номер блока, в котором хранятся 256 номеров блоков косвенной адресации. Этот блок называют блоком двойной косвенной адресации (double indirect block). Наконец, если и этого пространства для размещения файла недостаточно, последнее поле адресует номер блока, в котором хранятся 256 номеров блоков двойной косвенной адресации. Его называют блоком тройной косвенной адресации (triply indirect block).

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

На рис. 4.11 приведен inode, а на рис. 4.12 – фрагмент блока данных файла, содержащего сценарий (командный файл). Для этого файла был установлен дополнительный бит SUID, а также дополнительные атрибуты, предписывающие блокирование любых изменений файла, его автоматическое сжатие и декомпрессию при записи/чтении, а также гарантированное стирание блоков данных при удалении файла. Установка дополнительных

атрибутов производилась командой

chattr +ics file_name

INODE: 527744 (0x00080D80)

-rwsr-xr-x 0 0 69 Sat Apr 3 13:19:39 2004

TYPE: regular file

LINKS: 1

MODEFLAGS.MODE: 010.4755

SIZE: 69

BLOCK COUNT: 8

UID: 00000

GID: 00000

ACCESS TIME: Sat Apr 3 13:19:39 2004

CREATION TIME: Sat Apr 3 13:23:24 2004

MODIFICATION TIME: Sat Apr 3 13:19:39 2004

DELETION TIME: Thu Jan 1 05:00:00 1970

DIRECT BLOCKS: 0x001024F9

INDIRECT BLOCK:

DOUBLE INDIRECT BLOCK:

TRIPLE INDIRECT BLOCK:

Рис. 4.11. Информация о метаданных файла-сценария

0x024F9000 64 64 20 69 66 3D 2F 64: 65 76 2F 66 64 30 20 6F dd if=/dev/fd0 o

0x024F9010 66 3D 2F 68 6F 6D 65 2F: 66 6C 6F 70 70 79 5F 61 f=/home/floppy_a

0x024F9020 20 73 6B 69 70 3D 32 30: 20 63 6F 75 6E 74 3D 31 skip=20 count=1

0x024F9030 30 30 20 63 6F 6E 76 3D: 6E 6F 65 72 72 6F 72 2C 00 conv=noerror,

0x024F9040 73 79 6E 63 0A 00 00 00: 00 00 00 00 00 00 00 00 sync............

0x024F9050 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x024F9060 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x024F9070 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

0x024F9080 00 00 00 00 00 00 00 00: 00 00 00 00 00 00 00 00................

Рис. 4.12. Фрагмент блока данных файла-сценария

Однако в символьном виде inode (см. рис. 4.11) дополнительные атрибуты не отображаются. Их можно увидеть лишь в соответствующих полях таблицы индексных дескрипторов. В этом нет ничего странного: операционные системы непрерывно развиваются, и дополнительные атрибуты файлов появились несколько позже утилит, отображающих информацию о файлах.

Осталось рассмотреть, где и как размещается третий компонент файла – его символьное имя. У каждого inode может быть 65536 «жестких» ссылок, т. е. символьных имен. Ассоциативные связи между именами файлов и их индексными дескрипторами устанавливаются с помощью записей в каталогах, которые представляют собой разновидность текстовых файлов. Рассмотрим, как выглядит листинг одного из каталогов. На рис. 4.13 представлен фрагмент распечатки расширенных сведений о файлах, находящихся в каталоге /bin.

В первой строке приведена запись о самом каталоге /bin (он обозначен точкой). Двумя точками обозначается родительский, в данном случае корневой каталог. Расширенная информация содержит индексные дескрипторы, тип файлов и права доступа к ним, количество жестких ссылок (имен) файлов, владельца и его группу, размер файла, дату и время его создания и, наконец, само имя файла.

131329 drwxr-xr-x 2 root root 4096 Мар 18 17:42.

2 drwxr-xr-x 19 root root 4096 Апр 6 12:53..

Дата добавления: 2015-03-31