NTFS permissions not restored

[Vortex]

Hello synchronicity,

wimlib does not restore the NTFS permissions of a captured folder.

Here is how to reproduce the issue :

C:\Users\Vortex is an unused profile.

wimlib-imagex.exe capture C:\Users\Vortex profile1.wim

ren C:\Users\Vortex _Vortex
md C:\Users\Vortex

wimlib-imagex.exe apply profile1.wim 1 C:\Users\Vortex

The folder C:\Users\Vortex should have an entry for the user Vortex in the NTFS permissions. Everyone is listed in the permissions. ( which should not exist after the restoration process. )

No problem with the folder and file structure restoration.

Trying the same with imagex.exe Version 6.1.7600.16385 :

imagex.exe /capture C:\Users\Vortex Profile2.wim "Profile2"
ren C:\Users\Vortex _Vortex
md C:\Users\Vortex
imagex.exe /apply Profile2.wim 1 C:\Users\Vortex

imagex.exe restores correctly the NTFS permissions.

OS : Windows 7 Pro Sp1
I am operating with a user account which is a member of the Administrators group.

Thanks for creating and maintaining wimlib.

[Vortex]

Hello,

The same problem happens if I perform an on-line backup of Windows with the support of the volume shadow copy service. I wrote a tool named vscopy.exe similar to MS' volume shadow client vshadow.exe.

http://vortex.masmcode.com/files/vscopy101.zip

D:\Tools>vscopy.exe C: V: Capture.bat
Volume shadow copy path = \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

D:\Tools>wimlib-imagex.exe capture V: --compress=maximum Z:\XpPC.wim --check
Scanning "V:" (loading as root of WIM image)...
[WARNING] Running on Windows XP or earlier; alternate data streams will not be captured.
Writing LZX-compressed data using 2 threads
3009 MiB of 3009 MiB (uncompressed) written (100% done)
Calculating integrity table for WIM: 481 MiB of 481 MiB (100%) done

Capture.bat runs wimblib-imagex.exe to capture the volume shadow copy of the system partition. The backup is created on a network share symbolized with Z:

Restoring the image in the WinPE 1.x environment :

First, formatting the C drive.

D:\Tools>wimlib-imagex.exe apply Z:\XpPC.wim 1 C: --check
Verifying integrity of "Z:\0905PC.wim": 481 MiB of 481 MiB (100%) done
Applying image 1 ("V:") from "Z:\XpPC.wim" to directory "C:"
Extracting files: 3407 MiB of 3407 MiB (100%) done
Setting timestamps on all extracted files...
Done applying WIM image.

wimlib-imagex does not restore any NTFS permissions.

The .wim image is including the System Volume Information folder and pagefile.sys Shouldn't wimlib-imagex exclude them by default?

OS : Windows XP Sp3
Wimlib version : 1.4.2

[Vortex]

Concerning the test with with profile folder C:\Users\Vortex, imagex.exe version 6.1.7600.16385 is restoring correctly the NTFS permissions of the image captured by wimlib-imagex

[synchronicity]

Hi, thanks for reporting this. I believe I've fixed the problem, at least temporarily. It is very much hit-and-miss with these Windows API calls, though, since most are poorly documented. I attached a patched library for you to try out; just swap it with the current one. (Assuming you downloaded the 32 bit version.)

[Vortex]

Hello synchronicity,

I repeated the tests with the new DLL. This time, I was able to restore the NTFS permissions of the profile folder but the test with the volume shadow copy failed.

wimlib-imagex.exe capture V: --compress=maximum Z:\XpPC.wim --check

Capturing the volume shadow copy of the system partition works fine. wimlib-imagex reports the following error message when I try to restore the backup after booting to the WinPE environment :

D:\Tools\wimlib-imagex.exe apply Z:\XpPC.wim 1 C: --check
Verifying integrity of "Z:\XpPC.wim": 476 MiB of 476 MiB (100%) done
Applying image 1 ("V:") from "Z:\XpPC.wim" to directory "C:"
[ERROR] Failed to open "\?\C:\WINDOWS\Registration\CRMLog"
[ERROR] Win32 error: Access is denied.

[ERROR] Error extracting "\?\C:\WINDOWS\Registration\CRMLog"
ERROR: Exiting with error code 45:
Failed to open a file.

The restore process is stopping at this point.

Trying to access the CRMlog folder, I receive this error message displayed by a message box : C:\WINDOWS\Registration\CRMLog is not accesible. Access is denied.

I think wimlib-imagex does not restore correctly the NTFS permissions of this folder.

Imagex.exe restores successfully the operating system from the image XpPC.wim created by wimlib-imagex.exe

wimlib-imagex is capturing the System Volume Information folder and the file pagefile.sys Shouldn't the tool exclude them by default?

Thanks for your support.

[synchronicity]

Hi, thanks for testing again! I believe I've fixed both of the problems you've
identified:

• Files and directories not being excluded: This was caused by wimlib not handling \\?\-prefixed paths correctly when testing whether a file would be excluded or not. (As you may or may not be aware, paths on Windows have to be prefixed with \\?\ to fully support NTFS, which is why wimlib has to do it, although I knew that bugs like this would show up.)
• Access denied when restoring a certain directory: This was most likely caused by restoring a security descriptor so restrictive that it impeded the restore operation itself even when running as the Administrator. To work around this, I changed the code so that it applies security descriptors at the end, at the same time that timestamps are set. (I don't particularly like this solution since it can leave files without their final security descriptors for a long time, but given that Windows installations always seems to contain files and directories even the Administrator lacks various privileges on, this is probably best for now.)

Updated DLL file attached.

[Vortex]

Hello synchronicity,

Thanks for the new release of the DLL. It worked fine and wimlib-imagex restored correctly the NTFS permissions. I know the \?\ prefix but it didn't come to my mind to specify it while using wimlib-imagex.exe

I checked the NTFS permissions of the folders C:\WINDOWS\Registration and C:\WINDOWS\Registration\CRMLog. The Administrators group have full access on them.

[synchronicity]

Just to follow up on this: wimlib 1.5.0 should fix the problems you identified above. I also found other cases where backup and restore were subject to permissions problems similar to the one noted above. This was basically a result of the Windows security model and the fact that the Win32 API isn't ideal for backup and restore applications. In particular, some Win32 functions, such as GetFileSecurity() and FindFirstStream(), do not open their handles with "backup semantics" and can cause access denied errors even when running as the Administrator. To work around this, wimlib is now using the native Windows NT API in a few places, which although not ideal either should make things go much more smoothly, for example when reading streams and getting/setting security descriptors.

[Vortex]

Hello synchronicity,

Thanks for this new release. What are the NT APIs to backup and restore NTFS permissions? I have a tool to backup NTFS permissons ( based on GetFileSecurity) but as I understand I need to switch to NT APIs.

[synchronicity]

Hi,

First, the way you're doing it now is likely sufficient in 99.99% of cases, but I just wanted wimlib to work in 100% of cases if possible. The functions you could use are NtQuerySecurityObject() and NtSetSecurityObject(), which are located in ntdll and therefore should be loaded dynamically and only used if available. Also note that as per MS convention they are actually documented under the names ZwQuerySecurityObject() and ZwSetSecurityObject().

Note: the reason to do this, at least in the query case, is that GetFileSecurity() seems to be internally implemented by calling NtCreateFile() to open a handle to the file, then NtQuerySecurityObject() to query the security descriptor, then CloseHandle() or NtClose() to close it. But the call to NtCreateFile() is done without the FILE_OPEN_FOR_BACKUP_INTENT flag, which causes the SeBackupPrivilege that may have been acquired by the process to be ignored. Therefore it is possible to have a file or directory for which even the Administrator is unable to query the security descriptor using GetFileSecurity(). That's my understanding of it, anyway. So instead you need to open the file yourself with "backup intent" (e.g. CreateFile() with FILE_FLAG_BACKUP_SEMANTICS) and query the security descriptor on the handle.

Alternative functions to consider are GetSecurityInfo() and SetSecurityInfo(), but they're a bit clunky compared to the native calls.

[Vortex]

Hello synchronicity,

Applying a Windows 8 image captured with the --strict-acls option, I get the following error message :

X:\Tools\wimlib>wimlib-imagex.exe apply Z:\1311TBL.wim 1 C:\ --strict-acls
Applying image 1 ("1311TBL") from "Z:\1311TBL.wim" to directory "C:\"
Extracting files: 10 GiB of 10 GiB (100%) done
Setting timestamps on all extracted files...
[ERROR] Can't open \?\C:\Windows\WinSxS\x86_microsoft-windows-i..ntrolpanel.appxmain_31bf3856ad364e35_6.2.9200.20521_none_183093a4815e307f\Immersive Control Panel.lnk (5): File exists
[ERROR] Failed to set security descriptor on "\?\C:\Windows\WinSxS\x86_microsoft-windows-i..ntrolpanel.appxmain_31bf3856ad364e35_6.2.9200.20521_none_183093a4815e307f\Immersive Control Panel.lnk": No such process
ERROR: Exiting with error code 59:
Failed to set file owner, group, or other permissions on extracted file.

Second trial , without the --strict-acls option :

X:\Tools\wimlib>wimlib-imagex.exe apply Z:\1311TBL.wim 1 C:\ Applying image 1 ("1311TBL") from "Z:\1311TBL.wim" to directory "C:\"
Extracting files: 10 GiB of 10 GiB (100%) done
Setting timestamps on all extracted files...
[ERROR] Can't open \?\C:\Windows\WinSxS\x86_microsoft-windows-i..ntrolpanel.appxmain_31bf3856ad364e35_6.2.9200.20521_none_183093a4815e307f\Immersive Control Panel.lnk (5): File exists

Environment : Windows 8 PE
wimlib version : 1.6.1
I can boot successfully the restored OS after the second trial.

[synchronicity]

Can you double check that you're really using v1.6.1, including the libwim-9.dll file? If you're using the 32-bit version, libwim-9.dll should have a size of 305152 bytes. In v1.6.1 I made yet another change to how security descriptors are set on Windows, and the "Can't open ... " error message in that place no longer exists.

[Vortex]

Sorry, my apologies. While backing up, I used wimlib 1.6.1 My fault was to use an older version to restore the backup.