Файловая система NTFS и управление данными в Windows

Особенности файловой системы NTFS

Файловая система NTFS была разработана специально для использования в ОС Windows NT как замена для устаревшей системы FAT. NTFS является основной системой и для новых версий – Windows 2000/XP.

Система NTFS спроектирована как очень мощная многопользовательская файловая система с большим количеством возможностей. Тем не менее, как утверждают разработчики, NTFS обеспечивает более быстрый доступ к данным, чем предельно простая система FAT, если объем диска превышает 600 Мб.

Среди возможностей, отсутствующих в FAT, но реализованных в NTFS, можно назвать следующие.

· Развитые средства защиты данных, предотвращающие возможность несанкционированного доступа к данным и при этом позволяющие весьма детально разграничить права доступа для различных пользователей и групп пользователей.

· Быстрый поиск файлов в больших каталогах.

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

· Возможность сжатия данных на уровне отдельных файлов (т.е. на одном дисковом томе могут храниться файлы как в сжатом, так и в несжатом формате).

· Возможность хранения файлов в зашифрованном виде.

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

· Возможность протоколирования всех изменений, происходящих в файловой системе, таких как создание, изменение и удаление файлов и каталогов.

· Расширяемость системы. Учтя трудный опыт, связанный с попытками модернизации FAT, разработчики NTFS заранее заложили в систему возможность добавления новых, не предусмотренных в настоящее время атрибутов файлов.

Некоторые возможности, заложенные в файловую систему NTFS, даже опережают развитие ОС Windows и пока не могут быть использованы в этой системе.

Структуры дисковых данных

Общую структуру хранения данных на диске в системе NTFS часто характеризуют двумя короткими фразами:

На диске нет ничего, кроме файлов.

В файле нет ничего, кроме атрибутов.

Поговорим подробнее об этих загадочных утверждениях.

3.8.2.1. Главная таблица файлов

Наиболее важной частью файловой системы на диске является главная таблица файлов (MFT, Master File Table). Эта таблица содержит записи обо всех файлах и каталогах, расположенных на данном томе. Размер записи составляет один кластер, но не менее 1 Кб. Если метаданные о файле не помещаются в одной записи, то могут быть использованы дополнительные записи (не обязательно соседние).

После форматирования дискового тома, когда на нем еще нет пользовательских файлов, MFT содержит 16 записей, из которых 11 содержат описания файлов метаданных, а 5 зарезервированы как дополнительные. Список файлов метаданных достаточно интересен.

· Первая запись MFT описывает саму MFT, которая тоже считается файлом. Это отнюдь не формальность, поскольку MFT может, как и прочие файлы, состоять из нескольких сегментов, размещение которых задается в этой записи.

· Копия первых 16 записей MFT, которая хранится как файл где-нибудь в середине диска. Это позволяет восстановить метаданные в случае повреждения основного экземпляра MFT.

· Журнал протоколирования транзакций.

· Файл информации о томе: имя тома, серийный номер, дата форматирования и т.п.

· Файл с перечислением всех атрибутов, используемых для описания файлов на данном томе. Таким образом, список атрибутов не является жестко фиксированным и может быть расширен в последующих версиях NTFS.

· Корневой каталог тома.

· Битовая карта занятости кластеров тома.

· BOOT-сектор. Он по-прежнему является первым сектором тома, но тоже считается файлом.

· Файл, состоящий из всех дефектных кластеров на данном томе. Это дает основания пометить в битовой карте все дефектные кластеры как занятые.

· Файл, содержащий все различные дескрипторы защиты, используемые для файлов и каталогов данного тома (см. п. 3.8.4.2).

· Файл, задающий пары прописных / строчных букв для всех языков, поддерживаемых Windows. Такие данные необходимы, поскольку имена файлов могут содержать буквы обоих типов, но в Windows по традиции регистр букв в именах файлов не различается (в отличие, например, от UNIX).

· Каталог, содержащий еще 4 файла метаданных, добавленных в Windows 2000. К ним относятся:

- файл уникальных 16-байтовых идентификаторов, создаваемых Windows для каждого файла, на который имеется ярлык или OLE-связь; это позволяет автоматически исправить ярлык, если исходный файл был перемещен в другой каталог или даже на другой компьютер в пределах домена сети;

- файл квот дискового пространства, выделяемых каждому пользователю;

- файл точек повторного анализа, установленных для каталогов данного тома;

- файл журнала изменений, происходящих на томе.

Далее, начиная с 17-й позиции MFT, хранятся записи метаданных о файлах и каталогах, размещенных на данном томе.

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

Атрибуты файла

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

Атрибут в NTFS состоит из заголовка и значения, а заголовок, в свою очередь, содержит тип атрибута, его имя, длину и данные о размещении атрибута. Имя атрибута может отсутствовать, остальные поля обязательны. Заголовок атрибута всегда хранится в самой записи MFT, а значение – либо тоже в самой записи (при этом атрибут называется резидентным), либо в кластере области данных (нерезидентный атрибут). Некоторые типы атрибутов обязаны быть резидентными, для других типов выбор размещения зависит от наличия достаточного свободного места в записи MFT. Если атрибут нерезидентный, то в заголовке указываются сведения о размещении его значения на диске.

Рассмотрим наиболее важные типы атрибутов, используемых в записи о файле.

· Имя файла. Этот атрибут всегда резидентен. Допускается несколько атрибутов этого типа, например, «длинное» имя (до 255 символов, включая буквы любого языка) и имя «8 + 3» для того же файла.

· Стандартная информация. Это примерно та информация о файле, которая хранилась в записи каталога FAT: размер файла, временные штампы и битовые флаги.

· Дескриптор защиты. Он служит для задания прав доступа к данному файлу для различных пользователей и групп, подробнее см. п. 3.8.4.2. В новых версиях NTFS запись MFT содержит не сам дескриптор, а ссылку на его место в системном файле. Так получается компактнее, поскольку обычно на диске имеется много файлов с одинаковыми дескрипторами защиты и лучше хранить каждый дескриптор один раз, в специально отведенном для этого файле метаданных.

· Данные. Это самое неожиданное при первом знакомстве с NTFS: сами данные файла рассматриваются как один из типов атрибутов этого файла. Следующая неожиданность состоит в том, что атрибут данных небольшого файла может храниться резидентно в составе записи MFT. Напомним, что размер этой записи – от 1 Кб и больше, так что место для данных маленького файла может найтись. Безусловно, резидентное хранение данных позволяет ускорить доступ к ним, поскольку запись MFT так или иначе всегда читается при открытии файла.

Еще одна интересная особенность NTFS заключается в том, что один файл может иметь несколько атрибутов данных, определяющих несколько потоков данных (streams). Один из потоков безымянный, остальные должны иметь имена. Получается как бы целый каталог файлов внутри одного файла. Безусловно, для этой возможности можно придумать интересные применения, однако ни в одной версии Windows, включая XP, пока не предусмотрены API-функции, работающие с потоками данных.

Если запись MFT описывает не файл, а каталог, то вместо атрибута данных в ней содержится другой атрибут, содержащий либо весь каталог, либо его часть. Если каталог слишком велик, то другие его части хранятся в нерезидентных атрибутах еще одного типа. Здесь мы не будем рассматривать этот вопрос детально, однако следует отметить, что атрибуты, описывающие большой каталог, образуют структуру данных, известную как Б-дерево (B-tree). Эта структура позволяет ускорить поиск файла в каталоге.

Запись каталога содержит лишь имя файла, номер записи об этом файле в MFT и копию атрибута «стандартная информация». Эта копия позволяет отображать содержимое каталога без чтения записей MFT о каждом файле.

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

Доступ к данным

Windows предоставляет прикладным программам API-функцию CreateFile, которая может использоваться как для создания нового файла, так и для открытия существующего. В любом случае эта функция создает в системной памяти объект типа «открытый файл», именно потому название функции начинается со слова «Create».

Функция CreateFile может использоваться для работы с файлами любой файловой системы, поддерживаемой Windows (в частности, FAT и NTFS).

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

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

· Режим доступа. Может быть указан доступ для чтения, для записи или их комбинация.

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

· Атрибуты защиты. Их использование будет описано в п. 3.8.4.2.

· Режим создания. Определяет действия функции в случаях, когда файл с заданным именем уже существует и когда не существует. Определены следующие режимы.

- CREATE_NEW – Создается новый файл. Если файл уже существует, выдается ошибка.

- CREATE_ALWAYS – Создается новый файл в любом случае, даже если файл с таким именем уже существует.

- OPEN_EXISTING – Открывается существующий файл. Выдает ошибку, если файл не существует.

- OPEN_ALWAYS – Если файл существует, то он открывается, если не существует – создается новый файл.

- TRUNCATE_EXISTING – Открывается существующий файл, но все его содержимое удаляется. Если файл не существует, выдается ошибка.

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

К атрибутам файла относятся все те, которые Windows унаследовала от MS-DOS (только для чтения, скрытый, системный, архивный), а также атрибут «сжатый» (т.е. файл, создаваемый в NTFS, будет храниться в сжатом виде) и атрибут «временный». Этот атрибут означает, что файл, вероятно, будет скоро удален, а поэтому система должна попытаться удержать его данные в памяти, не тратя зря время на запись файла на диск.

Флаги функции предоставляют, в частности, следующие возможности:

· при операциях записи немедленно выполнять запись на диск (очищать кэш-буфера файла);

· вообще исключить использование кэша для данного файла, всегда записывать и читать секторы данных непосредственно с диска;

· указать системе желательность оптимальной буферизации для последовательного доступа или, наоборот, для произвольного доступа;

· открыть файл для выполнения асинхронных операций;

· указать системе, что файл должен быть автоматически удален сразу же, как только он будет закрыт.

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

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

Как вы думаете, почему при асинхронных операциях не используется указатель чтения/записи?

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

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

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

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

Защита данных

Средства безопасности в Windows NT/2000/XP представляют собой отдельную подсистему, которая обеспечивает защиту не только файлов, но и других типов системных объектов. Файлы и каталоги NTFS представляют собой наиболее типичные примеры защищаемых объектов.

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

Аутентификация пользователя

Важным элементом любой системы защиты данных является процедура входа в систему, при которой выполняется аутентификация пользователя. В Windows NT для вызова диалога входа в систему используется известная «комбинация из трех пальцев» – Ctrl+Alt+Del. Как утверждают разработчики, никакая «троянская» программа не может перехватить обработку этой комбинации и использовать ее с целью коллекционирования паролей.

Не хочет ли кто-нибудь попробовать?

Система ищет введенное имя пользователя сначала в списке пользователей данного компьютера, а затем и на других компьютерах текущего домена локальной сети. В случае, если имя найдено и пароль совпал, система получает доступ к учетной записи (account) данного пользователя.

На основании сведений из учетной записи пользователя система формирует структуру данных, которая называется маркером доступа (access token). Маркер содержит идентификатор пользователя (SID, Security IDentifier), идентификаторы всех групп, в которые включен данный пользователь, а также набор привилегий, которыми обладает пользователь.

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

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

Дескриптор защиты

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

Основным содержанием атрибутов защиты является другая структура – дескриптор защиты. Этот дескриптор содержит следующие данные:

· идентификатор защиты (SID) владельца объекта;

· идентификатор защиты первичной группы владельца объекта;

· пользовательский («дискреционный», «разграничительный») список управления доступом (DACL, Discretionary Access Control List);

· системный список управления доступом (SACL, System Access Control List).

Пользовательский список управляет разрешениями и запретами доступа к данному объекту. Изменять этот список может только владелец объекта.

Системный список управляет только аудитом доступа данному объекту, т.е. задает, какие действия пользователей по отношению к данному объекту должны быть запротоколированы в системном журнале. Изменять этот список может только пользователь, имеющий права администратора системы.

В Windows, в отличие от многих других ОС, администратор не всесилен. Он не может запретить или разрешить кому бы то ни было, даже самому себе, доступ к чужому файлу. Другое дело, что администратор имеет право объявить себя владельцем любого файла, но потом он не сможет вернуть файл прежнему хозяину. Подобные ограничения вытекают из понимания, что администратор тоже не всегда ангел и, хотя он должен иметь в системе большие права, его действия следует хоть как-то контролировать.

Оба списка управления доступом имеют одинаковую структуру, их основной частью является массив записей управления доступом (ACE, Access Control Entity).

Рассмотрим структуру записи ACE. Она содержит:

· тип ACE, который может быть одним из следующих: разрешение, запрет, аудит;

· флаги, уточняющие особенности действия данной ACE;

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

· идентификатор (SID) пользователя или группы, чьи права определяет данная ACE.

Более интересен пользовательский список. Он может содержать только записи разрешения и запрета. В начале списка всегда идут запрещающие записи, затем разрешающие.

Когда пользователь запрашивает доступ к объекту (т.е., например, программа, запущенная этим пользователем, вызывает функцию открытия файла), происходит проверка прав доступа. Она выполняется на основе сравнения маркера доступа пользователя со списком DACL. Система просматривает по порядку все записи ACE из DACL, для каждой ACE определяет записанный в ней SID и сверяет, не является ли он идентификатором текущего пользователя или одной из групп, куда входит этот пользователь. Если нет, то данная ACE не имеет к нему отношения и не учитывается. Если да, то выполняется сравнение прав, необходимых пользователю для выполнения запрошенной операции с маской видов доступа из ACE. При этом права анализируются весьма детально: например, открытие файла на чтение подразумевает наличие прав на чтение данных, на чтение атрибутов (в том числе владельца и атрибутов защиты), на использование файла как объекта синхронизации (см. п. 4.5.5.2).

Если в запрещающей ACE найдется хотя бы один единичный бит в позиции, соответствующей одному из запрошенных видов доступа, то вся операция, начатая пользователем, считается запрещенной и дальнейшие проверки не производятся.

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

Как выдумаете, почему в списке DACL сначала идут запрещающие ACE, а только потом разрешающие?

Таким образом, говоря кратко, пользователь получит доступ к объекту только в том случае, если все запрошенные им виды доступа явным образом разрешены и ни один их них не запрещен.

В годы перестройки много писалось о двух противоположных принципах: «запрещено все, что не разрешено» или «разрешено все, что не запрещено». В Windows все гораздо строже: запрещено все, что запрещено, и все, что не разрешено.

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

Имеются также два крайних случая. Список DACL может совсем отсутствовать (для этого достаточно, например, при создании файла указать NULL вместо атрибутов защиты), при этом права доступа не проверяются, все действия разрешены всем пользователям. Список DACL может присутствовать, но иметь нулевую длину (нет ни одной ACE). Как следует из общих правил, в этом случае в доступе будет отказано всем, в том числе и хозяину файла.

Управление процессами