First of all, let me fix errors in my code:
Qos.Length = sizeof(SECURITY_QUALITY_OF_SERVICE);
Qos.ImpersonationLevel = SecurityImpersonation;
Qos.ContextTrackingMode = SECURITY_DYNAMIC_TRACKING;
Qos.EffectiveOnly = 1;
InitializeObjectAttributes(&ObjAttr, &FileName, OBJ_CASE_INSENSITIVE, NULL, NULL);
RtlInitUnicodeString(&FileName, L"\??\C:\Windows\1.ini");
ObjAttr.SecurityQualityOfService = &Qos;
Status = NtCreateFile(&Handle,
GENERIC_READ | SYNCHRONIZE,
&ObjAttr,
&IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ | FILE_SHARE_WRITE,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE | 0x20000,
NULL,
0);
When I tried to run this example under restricted account,
it still reparsed C:\Windows\1.ini
to C:\Users\VMUSER\AppData\Local\VirtualStore\Windows\1.ini.
I will look further at the issue and post results here.
L.
I’ve asked the luafv folks and they had this to say (about the OP):
We have seen this before. the results are expected, because “more” in step #3 is a Windows “external” utility (%windir%\system32\more.com) which is not eligible for file virtualization. If you say “type \Windows\1.ini” instead, you should see the expected results. Because “type” is an internal cmd command, so if your cmd window is virt enabled, then “type” sould show the virtualized version of the file.
It is a common misconception that in step #3 anything done from a virt-enabled cmd prompt is virt-enabled. That’s generally not true; it depends on whether it is done in-proc or out-of-proc. While “type” is in-proc, “more” is out-of-proc, and it just happens to choose to disable virt.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
Thanks for the answer.
Yes, I think you are right and that’s exactly the case.
The same scenario with “type” command instead of “more” gives an expected
results (the updated copy of the file is presented),
since “type” is an inner command of the virtualized shell.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
Interesting.
From what I saw, More.com does a strange call to NtCreateFile,
which looks like this:
SECURITY_QUALITY_OF_SERVICE Qos;
OBJECT_ATTRIBUTES ObjAttr;
IO_STATUS_BLOCK IoStatus;
UNICODE_STRING FileName;
NTSTATUS Status;
HANDLE Handle;
Qos.Length = sizeof(SECURITY_QUALITY_OF_SERVICE);
Qos.ImpersonationLevel = SecurityImpersonation;
Qos.ContextTrackingMode = SECURITY_DYNAMIC_TRACKING;
Qos.EffectiveOnly = 1;
InitializeObjectAttributes(&ObjAttr, &FileName, OBJ_CASE_INSENSITIVE,
NULL, &Qos);
RtlInitUnicodeString(&FileName, L"\??\C:\Windows\1.ini");
Status = NtCreateFile(&Handle,
GENERIC_READ | SYNCHRONIZE,
&ObjAttr,
&IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ | FILE_SHARE_WRITE,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT |
FILE_NON_DIRECTORY_FILE | 0x200000,
NULL,
0);
NtClose(Handle);
Note that 0x20000 is FILE_DISALLOW_EXCLUSIVE (defined in WDK headers
for Windows 7).
When I tried to make the same call, it failed with STATUS_UNKNOWN_REVISION.
as result). But perhaps the non-NULL value of SECURITY_QUALITY_OF_SERVICE
means that the thread is running impersonated, so file virtualization
is disabled for that call ?
BTW it happens on 32-bit Win7 as well.
L.