Где Windows хранит списки ACL и отслеживает ли ACL файл с одного компьютера на другой? - PullRequest
7 голосов
/ 08 мая 2009

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

Таким образом, мой вопрос, хранятся ли ACL в файле таким образом, что они следуют за файлом на протяжении всей его жизни, особенно когда файл лицензии был сгенерирован на моей машине dev (машина 1), сохранен в Subversion (машина 2), извлечен контроля исходного кода TeamCity (компьютер 3), упакованный в установщик с помощью InstallShield (компьютер 4), и, наконец, развернутый на компьютере клиента (компьютер 5), где он был установлен администратором? Как насчет того, чтобы после того, как я сгенерировал файл на своем компьютере разработчика (машина 1), загрузил его поставщику компонента через его сайт поддержки (машина 2), а специалист службы поддержки загрузил его на свой компьютер для проверки (машина 3)?

Я не знаю этого наверняка (вот почему я спрашиваю об этом здесь), но я предположил, что каждая машина Windows хранит ACL в некотором центральном каталоге / списке / таблице, управляемой NTFS, а не хранящейся в файле. Что происходит с ACL исходного файла, когда он копируется с одного компьютера на другой, сохраняется в Subversion, упаковывается в MSI и т. Д.? Может кто-нибудь указать мне хорошие ссылки, где я могу прочитать об этом?

1 Ответ

14 голосов
/ 08 мая 2009

ACL хранятся в той части NTFS-раздела, которая выполняет всю фоновую обработку - MFT (Master File Table).

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

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

Если вы скопируете файл или переместите его на другой раздел или компьютер (который на самом деле является операцией копирования + удаления), скопированный файл по умолчанию унаследует разрешения своего нового контейнера (точнее, только наследуемые) .

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

Но поскольку ACL может содержать SID, которые «принадлежат домену», запись ACL может на самом деле не иметь смысла для целевого компьютера, который не является частью того же домена (например, когда вы берете домой USB-диск в формате NTFS) , В этом случае запись ACL не будет иметь никакого эффекта.

Другие идентификаторы SID "хорошо известны", такие как SID "SYSTEM". Они будут фактически распознаны через границы домена.

...