9

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

Теперь я узнал, что есть статья в КБ, объясняющая причину этого:

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

Таким образом, пользователь переместил файл из одной папки в другую, и права доступа к исходной папке были сохранены.

Мой вопрос сейчас: почему существует это исключение? В чем причина этого?

3 ответа3

9

Я объяснил это в блоге http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/, но это также объясняется ниже.

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

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

Когда файл перемещается в том же объеме, ничего не происходит (на уровне диска). Он просто меняет логический путь к файлу. Фактические данные и физический файл на диске не были затронуты или изменены. Вы когда-нибудь замечали, что когда вы перемещаете файл 5 ГБ в другую папку на том же диске, это делается практически мгновенно? Вот почему, потому что он фактически не перемещался, но указатель на то, где файл логически существует, изменился. Так как он не был изменен, разрешения также не меняются.

Это причина такого поведения.

Изменить: то, что я забыл упомянуть ... Статья MS не совсем точна. MS цитата:

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

Приведенная выше цитата относится только к объектам, которым были даны ТОЛЬКО определенные разрешения sec (отключить наследование). Как уже упоминалось в моих комментариях, это все о том, чтобы записи ACL были максимально эффективными. Рассмотрим следующий пример:

Для простоты объяснения, скажем, у вас есть папка, позволяющая пользователям изменять только права. Ниже приведены тысячи файлов, и ни один из них не имеет явных разрешений. Не очень эффективно создавать списки ACL для каждого файла, поскольку они имеют одинаковые права доступа, поэтому он устанавливает ОДНУ запись ACL для папки. Этот следующий бит очень важен для понимания; Сами файлы не имеют ACL PERMS. Поэтому, когда вы перемещаете какой-либо из этих файлов в новую папку на том же томе, MS заявляет, что с ним перемещаются привилегии (как указано выше). Задай себе вопрос .... как? Там не было никаких разрешений на файл в первую очередь для перемещения. Это на самом деле неверно, и я только что проверил это сейчас, чтобы подтвердить это. Допустим, папка назначения, в которую вы перемещаете файл, имеет права доступа, чтобы разрешить изменять права только для каждой группы. Хорошо, поскольку файл не имеет ACL напрямую, он наследует ACL родительской папки. Это означает, что разрешения изменились с изменения пользователя (старая папка) на изменение каждого (новая папка).

Заметьте разницу ?? На этот раз перемещение файла в другую папку на том же томе фактически изменило правила, что-то, что MS говорит, что не делает. Я только что нашел ошибку в документации MS с 2000 года?

Теперь рассмотрим тот же сценарий при использовании явных разрешений. Если вы установили явные разрешения для файла в этой папке (наследование отключено), который, например, запрещает пользователям доступ для чтения, он теперь создает новую запись ACL специально для этого файла. Теперь, когда вы перемещаете файл в новое место, он имеет запись ACL, непосредственно связанную с ним. В этом случае перемещение файла в новое место на том же томе ОСТАВЛЯЕТ его разрешения (как утверждает MS)!

6

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

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

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

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

  • Чтобы сохранить разрешения при копировании или перемещении файлов и папок, используйте утилиту Xcopy.exe с ключом /O или /X. Исходные разрешения объекта будут добавлены к наследуемым разрешениям в новом местоположении.

  • Чтобы добавить исходные разрешения объекта к наследуемым разрешениям при копировании или перемещении объекта, используйте утилиту Xcopy.exe с переключателями –O и –X.

1

ОК, это настоящий низкий уровень. Первый - мы говорим об одном ПК или сервере? Я предполагаю, что мы говорим о сервере. Итак ... как администратор Wintel компании A вы создаете файловую систему на сетевом диске вашего нового сервера. Вы основываете его на отделах, то есть у каждого отдела есть папка, и у каждой папки есть свой собственный уникальный ACL из-за проблем конфиденциальности, как, вероятно, норма - да? Поэтому, если вы собираетесь переместить файл в папку другого отдела, с какой стати вы НЕ хотите, чтобы он унаследовал привилегии своей новой папки? Что я имею в виду ... почему у вас есть файловая система на основе разрешений, если вы не собираетесь ее использовать? Я могу привести вам реальный пример, в котором важно, чтобы перемещенные файлы / папки всегда наследовали ACL родительской папки, просто спросите меня.

Перемещение файлов внутри тома или перемещение их с тома X на том Y ... в чем заключается существенная разница? Насколько я вижу, вы перемещаете расположение некоторых файлов - на разных томах или нет, - это мало что меняет в корпоративной среде. Настоящая причина, по которой один включает наследование по умолчанию, а другой еще не был упомянут Макером, - это "эффективность". Перетаскивание файлов внутри тома просто меняет запись в индексе - файлы не перемещаются, а информация ACL остается в одиночестве. Делает для простой операции. Однако, когда файлы перемещаются между томами, файлы и их списки ACL должны быть переопределены, поэтому правильное выполнение этого и включение наследования имеет смысл, так как не приводит к ненужным накладным расходам.

Я не могу понять, почему Microsoft не решает эту проблему. Было бы слишком сложно включить диалоговое окно как часть проводника drag n drop? Что-то типа «Вы переместили файлы в папку с разными правами доступа, хотите ли вы наследовать разрешения новой родительской папки? Y или N?"

С уважением, Stonegiant

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .