Ntfs права при копировании и перемещении
NTFS — основная файловая система в последних версиях Windows и Windows Server — предоставляет полный набор возможностей, включая дескрипторы безопасности, шифрование, дисковые квоты и расширенные метаданные. Ее можно использовать с общими томами кластера (CSV) для предоставления томов непрерывной доступности, доступ к которым можно осуществлять одновременно с нескольких узлов отказоустойчивого кластера.
Дополнительные сведения о функциях см. в этом разделе далее в этой статье. См. сведения о новой системе Resilient File System (ReFS).
Поддержка больших томов
NTFS может поддерживать тома размером до 8 ПБ в версии Windows Server 2019 и выше и Windows 10 версии 1709 и выше (более ранние версии поддерживают до 256 ТБ). Поддерживаемые размеры томов зависят от размера кластеров и их количества. Для кластеров (2 32 –1) (максимальное число кластеров, поддерживаемое NTFS) поддерживаются следующие размеры томов и файлов.
Размер кластера | Самый крупный том и файл |
---|---|
4 КБ (размер по умолчанию) | 16 ТБ |
8 КБ | 32 ТБ |
16 КБ | 64 ТБ |
32 КБ | 128 ТБ |
64 КБ (предыдущий максимальный размер) | 256 ТБ |
128 КБ | 512 ТБ |
256 KB | 1 ПБ |
512 КБ | 2 ПБ |
1024 КБ | 4 ПБ |
2048 КБ (максимальный размер) | 8 ПБ |
Обратите внимание, что при попытке подключить том с размером кластера, который превышает поддерживаемый максимум используемой версии Windows, вы получите ошибку STATUS_UNRECOGNIZED_VOLUME.
Службы и приложения могут накладывать дополнительные ограничения на размер файлов и томов. Например, ограничение размера тома составляет 64 ТБ, если вы используете функцию предыдущих версий или приложение резервного копирования, которое использует моментальные снимки службы теневого копирования томов (и не используете сеть SAN или RAID). Тем не менее, может потребоваться использовать тома меньшего размера в зависимости от рабочей нагрузки и производительности хранилища.
Максимальная длина имени файла и пути к файлу
NTFS поддерживает длинные имена файлов и пути увеличенной длины со следующими максимальными значениями:
Поддержка длинных имен файлов с обратной совместимостью. NTFS допускает длинные имена файлов, сохраняя псевдоним 8.3 на диске (в кодировке Юникод), чтобы обеспечить совместимость с файловыми системами, которые накладывают ограничение 8.3 на имена и расширения файлов. При необходимости (по соображениям производительности) можно выборочно отключить именование 8.3 на отдельных томах NTFS в Windows Server 2008 R2, Windows 8 и более поздних версиях операционной системы Windows. В Windows Server 2008 R2 и более поздних версий короткие имена по умолчанию отключены при форматировании тома с помощью операционной системы. Для совместимости приложений на системном томе все еще включены короткие имена.
поддержка путей расширенной длины. многие функции API Windows имеют версии юникода, позволяющие использовать расширенный путь длиной приблизительно 32 767 символов, за исключением ограничений по сравнению с 260 символами, определенными параметром MAX_PATH. Подробные требования к именам файлов и формату путей, а также рекомендации по реализации путей увеличенной длины см. в статье Naming Files, Paths, and Namespaces (Имена файлов, пути и пространства имен).
Кластерное хранилище. При использовании в отказоустойчивых кластерах NTFS поддерживает постоянно доступные тома, к которым могут одновременно обращаться несколько узлов кластера при использовании совместно с файловой системой CSV. Дополнительные сведения см. в статье Use Cluster Shared Volumes in a Failover Cluster (Использование общих томов кластера в отказоустойчивом кластере).
Явные и неявные разрешения
Все разрешения, которые наследуются автоматически, именуются неявными (implicit). И напротив, разрешения, которые устанавливаются вручную путём изменения ACL, называются явными (explicit). Отсюда вытекают два правила:
• На одном уровне вложенности запрещающее разрешение имеет более высокий приоритет. Если для одного SID было задано и разрешающее, и запрещающее разрешение, то действовать будет запрет.
• Явное разрешение имеет более высокий приоритет, чем неявное. Если запрет на какой-то объект был унаследован от родителя, а затем на него было установлено явное разрешение, то оно получит приоритет.
Таким образом в NTFS формируются комбинации разрешений и запретов. И если расположить приоритеты разрешений в порядке убывания, то получим примерно такую картину:
1. Явный запрет
2. Явное разрешение
3. Неявный запрет
4. Неявное разрешение
Сводка
В Microsoft Windows 2000, Windows Server 2003 и Windows XP у вас есть возможность использовать файловую систему FAT32 или файловую систему NTFS. При использовании NTFS вы можете предоставить разрешения папок и файлов для управления доступом к этим объектам. При копировании или перемещении файла или папки в томе NTFS в зависимости от того, копируется или перемещается объект в том же NTFS или в другой том, Windows Explorer обрабатывает разрешения на объекте.
Повышенная безопасность
Безопасность на основе списка управления доступом (ACL) для файлов и папок. NTFS позволяет устанавливать разрешения для файла или папки, указывать группы и пользователей, чей доступ требуется ограничить или разрешить, и выбрать тип доступа.
Поддержка шифрования диска BitLocker. Шифрование диска BitLocker обеспечивает дополнительную безопасность важных системных сведений и других данных, хранящихся на томах NTFS. Начиная с Windows Server 2012 R2 и Windows 8.1, BitLocker поддерживает шифрование устройств на компьютерах с архитектурой x86 и x64 с доверенным платформенным модулем, который поддерживает режим ожидания с подключением (ранее доступный только на устройствах Windows RT). Шифрование устройств помогает защитить данные на компьютерах под управлением Windows и помогает предотвратить доступ пользователей-злоумышленников к системным файлам, которые они используют для обнаружения пароля, или к диску путем физического удаления его с компьютера и установки в другой компьютер. Дополнительные сведения см. в статье What's New in BitLocker (Новые возможности BitLocker).
Атрибуты и ACL
При работе через сервер права доступа выдаются сервером, при непосредственной же работе с дисками через интерфейс локальной машины права доступа выдаются на уровне файловой системы NTFS. Как это работает? А вот как. Каждый записанный в NTFS файл представляет собой не только данные, помимо них он также хранит служебную информацию — атрибуты и ACL (Access Control List). Кстати, атрибуты и ACL имеют не только файлы, но и папки.
Что такое атрибуты файла, вы, в принципе, должны знать сами. Скрытый, системный, индексируемый или неиндексируемый, доступный только для чтения, готовый к архивированию — всё это называется атрибутами и просматривается в свойствах файла или папки. За права же доступа отвечают метаданные ACL. И если атрибуты описывают свойства объекта, то ACL указывает, кто именно и какие действия с этим объектом может производить. ACL также именуют разрешениями.
Структуру ACL можно представить в виде таблицы с тремя колонками.
Первая колонка содержит уникальный идентификатор пользователя (SID) , вторая — описание прав (read, write и т.д.) , третья — флаг , указывающий разрешено ли конкретному SID пользоваться этими правами или нет. Он может принимать два значения: true (да) и false (нет).
Основных прав доступа в NTFS четыре:
• Read разрешает только чтение файла.
• Write разрешает чтение и запись.
• Modify разрешает чтение, запись, переименование, удаление и редактирование атрибутов.
• Full Control даёт пользователю неограниченную власть над файлом. Помимо всего перечисленного, имеющий права Full Control пользователь может редактировать метаданные ACL. Все прочие права доступа возможность изменения ACL не предоставляют.
Динамическое выделение емкости
Если пространство тома ограничено, NTFS предоставляет следующие возможности для работы с емкостью хранилища сервера:
К ак и в реальном мире, в мире компьютеров и интернета есть вещи, которыми мы можем обладать и есть вещи, которыми мы обладать не можем. А не можем потому, что не имеем на них прав. Объяснять, для чего собственно были придуманы все эти разрешения и права доступа, полагаем, не нужно. Если бы их не было, любой пользователь мог бы просматривать, изменять и удалять любые не принадлежащие ему файлы не только на локальных машинах, но и на серверах.
С понятиями прав и разрешений на файлы более или менее знакомы все пользователи. Но что в действительности они собой представляют и как система определяет, какой файл можно просматривать или изменять, а какой нет? Давайте попробуем разобраться.
Начнем с того, что большая часть всех данных хранится на дисках в виде файлов, к которыми пользователи тем или иным образом получают доступ. Пример, когда пользователь получает доступ к файлам не напрямую, а через веб-сервер, мы рассматривать не будем. Скажем лишь, что такие данные, помимо прочих разрешений, также имеют особое разрешение share , наличие которого проверяется при обращении к удалённому серверу.
Требования к форматированию для больших файлов
Есть новые рекомендации по форматированию томов в отношении правильного расширения больших файлов VHDX. В ходе форматирования томов, которые будут использоваться при дедупликации данных, или при размещении очень больших файлов, таких как файлы VHDX размером больше 1 ТБ, используйте в Windows PowerShell командлет Format-Volume со следующими параметрами.
Параметр | Описание |
---|---|
-AllocationUnitSize 64KB | Задает размер единицы распределения NTFS 64 КБ. |
-UseLargeFRS | Включает поддержку сегментов записей больших файлов (FRS). Это необходимо для увеличения количества экстентов, допустимых для каждого файла в томе. Для больших записей FRS ограничение увеличивается с примерно 1 500 000 до 6 000 000 экстентов. |
Например, следующий командлет форматирует диск D как том NTFS с включенными FRS и размером единицы распределения 64 КБ.
Можно также использовать команду format. В системной командной строке введите следующую команду, где /L форматирует большой том FRS, а /A:64k задает размер единицы распределения 64 КБ:
повышенная надежность;
NTFS использует файл журнала и сведения о контрольных точках для восстановления согласованности файловой системы при перезагрузке компьютера после сбоя системы. После ошибки поврежденного сектора NTFS динамически изменяет конфигурацию кластера, содержащего поврежденный сектор, выделяет новый кластер для данных, отмечает исходный кластер как поврежденный и больше не использует старый кластер. Например, после сбоя сервера NTFS может восстановить данные путем воспроизведения файлов журнала.
NTFS непрерывно отслеживает и исправляет временные проблемы повреждения в фоновом режиме, не переводя том в автономный режим (эта функция, введенная в Windows Server 2008, известна как NTFS с самовосстановлением). При значительных проблемах с повреждением программа Chkdsk в Windows Server 2012 и более поздних версиях сканирует и анализирует диск, пока том подключен, ограничивая время автономной работы временем, необходимым для восстановления целостности данных в томе. Когда NTFS используется с CSV, простои не требуются. Дополнительные сведения см. в статье NTFS Health and Chkdsk (Работоспособность NTFS и Chkdsk).
Наследование
Так как файлов на диске может быть очень много и большая их часть располагается во вложенных каталогах, для удобного и быстрого изменения их прав доступа необходим какой-то механизм. Для этого в NTFS есть такая вещь как наследование .
Правило наследования простое и укладывается оно в одну формулировку: при своём создании каждый дочерний объект автоматически наследует разрешения ближайшего родительского объекта. Приведём пример. Если вы создали папку «А», а в ней папку «Б», то папка «Б» будет иметь те же разрешения, что и папка «А». Следовательно, все файлы в папке «Б» получат разрешения папки «А» .
Особенности наследования при копировании и перемещении файлов
До этого момента мы говорили о наследовании при создании файлов в родительских или дочерних каталогах. В случаях копирования или перемещения объекта правила наследования меняются .
• При копировании объекта с одного тома на другой, например, с диска «С» на диск «D» копируемый объект всегда получает права или разрешения того раздела или расположенного в нём каталога, в который он копируется. Те же правила действуют при перемещении файлов между разными томами.
• При перемещении в пределах одного тома, перемещаемый объект сохраняет свою ACL, изменяется только ссылка на него в таблице MFT.
• При копировании в пределах одного тома копируемый объект получает ACL от ближайшего вышестоящего родительского каталога.
Для начала этого вполне достаточно, чтобы иметь более-менее чёткое представление о том, как работают законы разрешений в NTFS. На самом деле разрешений в файловой системе существует гораздо больше разрешений. Большинству простых пользователей их знать необязательно, а вот будущим системным администраторам такие знания могут очень даже пригодится.
В файловой системе NTFS каждый объект (файл или папка) имеет свой список контроля доступа (Access Control List, ACL), в котором содержится информация о том, кто (или что) имеет доступ к объекту и какие операции разрешено (или запрещено) этому субъекту проводить над объектом. А что происходит с ACL при копировании или перемещении объекта? Попробуем это выяснить …
В качестве подопытного возьмем папку Temp в корне диска C. Откроем свойства папки и посмотрим ее разрешения. Как видите, в списке доступа есть только группа локальных администраторов и пользователь kirill (то есть я :)).
Теперь возьмем нашу папку.
И помощью Проводника скопируем ее на компьютер SRV1, также в корень диска C.
Если посмотреть разрешения скопированной папки, то мы увидим, что они полностью изменились.
Для того чтобы понять, откуда взялись новые разрешения, пройдем в дополнительные параметры безопасности папки (кнопка Advanced). Как видно из рисунка, все разрешения папки Temp унаследованы от диска С.
В этой ситуации нет ничего удивительного. По умолчанию разрешения NTFS сохраняются только при копировании\перемещении в пределах одного логического диска, или тома. Если же объект перемещается на другой диск того же (или другого) компьютера, то все разрешения заменяются наследуемыми от родительского объекта, которым в нашем случае и является диск C компьютера SRV1.
В нашем случае скопирована всего лишь одна папка с несколькими файлами, поэтому при необходимости восстановить утерянные разрешения несложно. А если подобное случиться при переносе серьезного файлового ресурса с высоким уровнем вложенности и сложной структурой разрешений NTFS, заданных вручную ?
К сожалению, проводник Windows не умеет копировать разрешения файловой системы, для этого нам придется воспользоваться альтернативными средствами.
Утилита Icacls
Эта утилита специально предназначена для работы с ACL. В числе прочего она может сохранить список доступа указанного объекта в файл, а затем применить этот список к указанному объекту.
Открываем командную консоль и сохраняем ACL исходного каталога Temp со всем его содержимым (подкаталоги и файлы) в файл tempACL командой:
Icacls C:\Temp\* /save tempACL /t
По умолчанию утилита сохраняет файл в профиле пользователя — C:\Users\Имя_пользователя. Это обычный текстовый файл, который при желании можно открыть в Блокноте.
Перенесем созданный файл tempACL на SRV1 и восстановим из него ACL каталога Temp командой:
Icacls C:\temp /restore C:\tempACL
Затем еще раз посмотрим разрешения скопированой папки Temp и увидим, что справедливость восторжествовала 🙂 и исходные разрешения восстановлены.
Утилита Xcopy
Xcopy является продвинутым вариантом команды Copy и в отличие от нее умеет работать с сетевыми путями, а также копировать сведения о владельце и данные ACL объекта.
В нашем случае для того, чтобы скопировать каталог Temp на SRV1 с сохранением списков доступа воспользуемся командой:
Xcopy C:\Temp \\SRV1\C$\Temp /E /O
Total Commander
Те, кто боится не любит работать в командной строке, могут воспользоваться файловым менеджером стороннего производителя, например Total Commander. В нем при копировании\переносе есть возможность скопировать разрешения NTFS, просто отметив галочкой чекбокс «Copy NTFS permissions».
И в завершение один важный момент, который учитывать при перемещении файловых ресурсов — разрешения NTFS можно свободно переносить только в пределах одного домена или леса доменов. Если к примеру скопировать папку со списком доступа на компьютер, не входящий в домен, то получим интересную ситуацию: ACL перенесен, но в локальной базе учетных записей нет такого пользователя. В этом случае при просмотре разрешений мы увидим примерно такую картину:
В этой статье описывается, как Windows Explorer обрабатывает разрешения файлов и папок в различных ситуациях.
Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 310316
Дополнительная информация
По умолчанию объект наследует разрешения от родительского объекта либо во время создания, либо при копировании или перемещении в родительную папку. Единственное исключение из этого правила возникает при переходе объекта в другую папку на том же томе. В этом случае исходные разрешения сохраняются.
Кроме того, обратите внимание на следующие правила:
Группе Everyone предоставляется разрешение на полный контроль корневого диска каждого диска NTFS.
Отказ в разрешении всегда имеет приоритет над разрешить разрешения.
Явные разрешения имеют приоритет над унаследованных разрешений.
Если разрешения NTFS конфликтуются, например, если разрешения групп и пользователей противоречивы, приоритет имеют наиболее либеральные разрешения.
Чтобы сохранить разрешения при копировании или перемещении файлов и папок, используйте Xcopy.exe с /O /X переключателем.
Первоначальные разрешения объекта будут добавлены к наследуемым разрешениям в новом расположении.
Чтобы добавить первоначальные разрешения объекта к наследуемым разрешениям при копировании или перемещение объекта, используйте Xcopy.exe с помощью и -O -X переключатели.
Чтобы сохранить существующие разрешения без добавления наследуемых разрешений из родительской папки, используйте утилиту Robocopy.exe, которая доступна в комплекте ресурсов 2000 Windows 2000.
Можно изменить, Windows Explorer обрабатывает разрешения при копировании или перемещении объектов в другой том NTFS. При копировании или перемещение объекта в другой том объект наследует разрешения новой папки. Однако если вы хотите изменить это поведение, чтобы сохранить исходные разрешения, измените реестр следующим образом.
В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, см. в этой информации, как создать и восстановить реестр в Windows.
Найдите и нажмите клавишу реестра: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer .
В меню Редактирование нажмите кнопку Добавить значение, а затем добавьте следующее значение реестра:
- Имя значения: ForceCopyAclwithFile
- Тип данных: DWORD
- Данные значения: 1
Закройте редактор реестра.
Можно изменить, Windows Explorer обрабатывает разрешения при перемещении объектов в том же объеме NTFS. Как уже упоминалось, при перемещении объекта в том же объеме объект сохраняет свои разрешения по умолчанию. Однако если вы хотите изменить это поведение, чтобы объект наследовал разрешения родительской папки, измените реестр следующим образом:
Найдите и щелкните подки реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer .
В меню Редактирование нажмите кнопку Добавить значение, а затем добавьте следующее значение реестра:
- Имя значения: MoveSecurityAttributes
- Тип данных: DWORD
- Данные значения: 0
Закройте редактор реестра.
Убедитесь, что учетная запись пользователя, используемая для перемещения объекта, имеет набор разрешений на изменение. Если разрешение не установлено, отдай разрешение на изменение учетной записи пользователя.
Значение реестра MoveSecurityAttributes применяется только к Windows XP и Windows Server 2003. Значение не влияет на Windows 2000.
Поскольку файлы являются защищаемыми объектами, доступ к ним регулируется моделью управления доступом, которая управляет доступом ко всем другим защищаемым объектам в Windows. Подробное описание этой модели см. в разделе Контроль доступа.
При вызове функции CreateFile, CreateDirectoryили креатедиректорекс можно указать дескриптор безопасности для файла или каталога. Если для параметра лпсекуритяттрибутес указано значение NULL , то файл или каталог получает дескриптор безопасности по умолчанию. Списки управления доступом (ACL) в дескрипторе безопасности по умолчанию для файла или каталога наследуются от родительского каталога. Обратите внимание, что дескриптор безопасности по умолчанию назначается только в том случае, если файл или каталог создается вновь, а не при его переименовании или перемещении.
Чтобы получить дескриптор безопасности объекта файла или каталога, вызовите функцию жетнамедсекуритинфо или жетсекуритинфо . Чтобы изменить дескриптор безопасности объекта файла или каталога, вызовите функцию сетнамедсекуритинфо или сетсекуритинфо .
Допустимые права доступа к файлам и каталогам включают в себя Удаление, _ Управление чтением, запись _ DAC, запись _ владельца и синхронизацию стандартных прав доступа. В таблице в константах прав доступа к файлу перечислены права доступа, относящиеся к файлам и каталогам.
Несмотря на то, что право на синхронизацию доступа определяется в стандартном списке прав доступа , чтобы указать маркер файла в одной из функций ожидания, при использовании асинхронных операций файлового ввода-вывода следует ожидать обработчика событий, содержащегося в правильно настроенной перекрывающейся структуре, вместо использования маркера файла с правом синхронизировать доступ для синхронизации.
Ниже перечислены универсальные права доступа к файлам и каталогам.
Право доступа | Описание |
---|---|
FILE_GENERIC_EXECUTE | FILE_EXECUTE FILE_READ_ATTRIBUTES STANDARD_RIGHTS_EXECUTE ПОЛНИТ |
FILE_GENERIC_READ | FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA STANDARD_RIGHTS_READ ПОЛНИТ |
FILE_GENERIC_WRITE | FILE_APPEND_DATA FILE_WRITE_ATTRIBUTES FILE_WRITE_DATA FILE_WRITE_EA STANDARD_RIGHTS_WRITE ПОЛНИТ |
Windows сравнивает запрошенные права доступа и сведения в маркере доступа потока со сведениями в дескрипторе безопасности объекта file или directory. Если при сравнении не запрещается предоставление всех запрошенных прав доступа, в поток возвращается маркер объекта, и предоставляются права доступа. Дополнительные сведения об этом процессе см. в разделе взаимодействие между потоками и защищаемые объекты.
По умолчанию авторизация доступа к файлу или каталогу контролируется исключительно списками управления доступом в дескрипторе безопасности, связанном с этим файлом или каталогом. В частности, дескриптор безопасности родительского каталога не используется для управления доступом к любому дочернему файлу или каталогу. Право доступа к файлу _ обхода может быть принудительно удалено путем удаления привилегий обхода _ перекрестной _ проверки для пользователей. Это не рекомендуется в общем случае, так как многие программы неправильно обрабатывают ошибки обхода каталогов. Основное использование право доступа к файлам _ в каталогах заключается в том, чтобы обеспечить соответствие определенным стандартам стандарта IEEE и ISO при обеспечении совместимости с системами UNIX.
модель безопасности Windows позволяет дочернему каталогу наследовать или предотвратить наследование одного или нескольких записей ace в дескрипторе безопасности родительского каталога. Каждый элемент ACE содержит информацию, определяющую, как она может быть унаследована, и будет ли она оказывать воздействие на наследуемый объект каталога. Например, некоторые унаследованные элементы управления доступом к объекту каталога наследуются и называются действующими записями ACE. Все остальные ACE называются только наследуемыми элементами управления доступом.
Windows модель безопасности также обеспечивает автоматическое наследование ace дочерними объектами в соответствии с правилами наследования ACE. Это автоматическое наследование вместе с информацией о наследовании в каждой записи ACE определяет, как ограничения безопасности передаются вниз по иерархии каталогов.
Обратите внимание, что вы не можете использовать ACE, запрещающий доступ, чтобы запретить доступ к файлу только для универсального _ чтения или только для общего доступа на _ запись . Это связано с тем, что для файловых объектов универсальные сопоставления универсальной операции _ чтения или универсальной _ записи включают право на синхронизацию доступа. Если ACE запрещает универсальный доступ на _ запись к доверенному лицу, а доверенное лицо запрашивает универсальный доступ для _ чтения , запрос завершится ошибкой, так как запрос неявно включает синхронизацию доступа, который неявно отклоняется элементом ACE, и наоборот. Вместо использования ACE, запрещенного доступом, используйте ACE, разрешенные доступом, чтобы явно разрешить разрешенные права доступа.
Другим способом управления доступом к объектам хранилища является шифрование. реализация шифрования файловой системы в Windows — это зашифрованная файловая система или EFS. EFS шифрует только файлы, а не каталоги. преимущество шифрования заключается в том, что он обеспечивает дополнительную защиту файлов, которые применяются к носителю, а не через файловую систему и стандартную архитектуру управления доступом Windows. Дополнительные сведения о шифровании файлов см. в разделе Шифрование файлов.
В большинстве случаев возможность чтения и записи параметров безопасности файла или объекта каталога ограничена процессами режима ядра. Очевидно, что не нужно, чтобы какой либо пользовательский процесс мог изменить владение или ограничение доступа к закрытому файлу или каталогу. Однако приложение резервного копирования не сможет завершить свое задание резервного копирования файла, если ограничения доступа, которые вы поместили в файл или каталог, не позволяют процессу пользовательского режима приложения прочитать его. Приложения резервного копирования должны иметь возможность переопределить параметры безопасности объектов файлов и каталогов, чтобы обеспечить полную архивацию. Аналогичным образом, если приложение резервного копирования пытается записать резервную копию файла на диск, а вы явно отклоните права записи для процесса резервного копирования, операция восстановления не может завершиться. В этом случае приложение резервного копирования должно иметь возможность переопределить параметры управления доступом к файлу.
для создания резервных копий приложений были специально созданы разрешения на доступ к имени _ резервного копирования _ SE и SE _ restore _ name . Если эти привилегии были предоставлены и включены в маркере доступа процесса приложения резервного копирования, можно вызвать функцию CreateFile , чтобы открыть файл или каталог для резервного копирования, указав стандартное право доступа на Чтение _ в качестве значения параметра двдесиредакцесс . Однако для обнаружения вызывающего процесса в качестве процесса резервного копирования вызов функции CreateFile должен включать флаг _ _ _ семантики резервного копирования флага файла в параметре двфлагсандаттрибутес . Полный синтаксис вызова функции приведен ниже.
Это позволит процессу резервного копирования открыть файл и переопределить стандартную проверку безопасности. Чтобы восстановить файл, приложение резервного копирования будет использовать следующий синтаксис вызова CreateFile при открытии файла для написания.
Существуют ситуации, когда приложение резервного копирования должно иметь возможность изменять параметры управления доступом к файлу или каталогу. Например, если параметры управления доступом к хранимой на диске копии файла или каталога отличаются от резервной копии. Это может произойти, если эти параметры были изменены после резервного копирования файла или каталога или если они были повреждены.
Флаг _ _ _ семантики резервного копирования флагов файлов , указанный в вызове функции CreateFile , дает приложению резервного копирования разрешение на чтение параметров управления доступом к файлу или каталогу. С этим разрешением процесс резервного копирования может вызывать жеткернелобжектсекурити и сеткернелобжектсекурити для чтения и, помимо сброса параметров управления доступом.
Если приложение резервного копирования должно иметь доступ к параметрам управления доступомна уровне системы, в значении параметра двдесиредакцесс , переданном в CreateFile, должен быть указан флаг _ _ безопасности системы Access .
Приложения резервного копирования вызывают баккупреад для чтения файлов и каталогов, указанных для операции восстановления, и баккупврите для их записи.
Владелец объекта
Кроме атрибутов и разрешений, каждый объект в файловой системе NTFS имеет своего владельца. Таковым может выступать локальный администратор, пользователь, TrustedInstaller, система и т.д. Владелец может изменять права доступа к своему файлу, однако локальный администратор имеет право назначить владельцем такого файла самого себя, следовательно, получить на него полные права, то есть Full Control .
Читайте также: