Applying a wim archive captured with --source-list and broken NTFS permissions

[Skyblue]

Hello,

After applying a wim archive captured with --source-list, I experienced some broken NTFS permissions problems. Here is a test.

Create a simple directory structure :

Code: Select all

md D:\test\abc
md D:\test\xyz
echo > D:\test\abc\sample1.txt
echo > D:\test\xyz\sample2.txt

Capture the directory :

Code: Select all

wimcapture.cmd list.txt archive.wim --source-list

list.txt :

Code: Select all

D:\test\abc /abc
D:\test\xyz /xyz

Remove the directory D:\test and restore the contents of the wim archive :

Code: Select all

rd /s /q D:\test
wimapply.cmd archive.wim D:\test

Checking the properties of the folder D:\test, I noticed that there were no any NTFS permissions assigned to this folder.
Recreating the folder with the command md D:\test before the wimapply operation does not have any effect, the same problem appears. Applying the same archive to the root of a partition is dangerous as all the NTFS permissions of the partition are removed :

Code: Select all

wimapply.cmd archive.wim R:\

Tested with wimlib 1.9.1 and 1.9.2 Beta 2 on Windows 7 Sp1 32-bit

[synchronicity]

Hi,

With regards to capturing the image: when a file or directory is added to a WIM image, wimlib creates any prerequisite ancestor directories with default metadata, including "no security descriptor". In your example, this applied to the root directory of the image. Since wimlib cannot, in general, know what security descriptor to use for such directories, this is probably the expected behavior for capturing the image.

It is when applying the image that the potentially unexpected behavior is introduced. Whenever wimlib extracts a directory which already exists, it initially sets a null DACL on that directory. This was not always the case, but it was introduced several versions ago as a workaround for a bug in Windows where Windows sometimes fails to honor "backup semantics" mode when opening named data streams. The null DACL will then remain on directories that do not have a security descriptor specified in the image.

I suppose that the expected behavior when applying would be for the original security descriptors to be retained on such directories. Do you agree? In the general case (to work around the bug I mentioned) wimlib may still have to temporarily change some security descriptors.

Thanks for the report!

- synchronicity

[Skyblue]

Hi synchronicity,

Thanks for your reply and the info. The original security descriptors should to be retained on such directories, I agree with you. Also, preserving the NTFS permissons of the root directories is important.

[synchronicity]

Good news --- I found a workaround for the Windows bug that does not require changing directories' security descriptors. This entirely avoids the problem you've described, as wimlib now will never change the existing security descriptors (except when it actually needs to set a security descriptor given in the WIM image, of course).

I have posted wimlib-1.9.2-BETA3 with the fix.

[Skyblue]

Hello synchronicity,

Thanks for the new release. It works fine on Windows XP SP3 and the NTFS permission problem is solved. I will repeat the test tomorrow on a Windows 7 system.

[Skyblue]

Hello synchronicity,

wimlib 1.9.2 Beta 4 tested on Windows 7 Sp1 and no broken NTFS permissions problem.