CurrentByteOffset is special because it’s updated by the file system on on
each (successful) synchronous read and write. It also is updated as a result
of IRP_MJ_SET_INFORMATION/FilePositionInformation.
You should also sync some other fields in PostCreate:
Sometimes higher filters look at these fields to check for data access. Note
that they shouldn’t change after PostCreate (though some filters will muck
with them for their own twisted reasons).
Thanks Scott. All seems OK except a problem I have hit with renames: both the parent FO (C:\Windows\System32\drivers\etc) and target FO (C:\Windows\System32\drivers\etc\hosts) are being ‘shadowed’ because the user is a standard user and MoveFileW requires FILE_ADD_FILE access for the parent and DELETE for the file itself. I positioned FileSpy below my driver and this is the output:
Process Request IRP Flags FileObject FO Flags Path Status More info
You can see the file and its parent being shadowed in #2 and #8 respectively (FFFFFA803422D610 is shadowed by FFFFFA8034B0BD60 and FFFFFA8031213730 is shadowed by FFFFFA8031696670)
In my driver I see #8 come through with the path […]etc\hosts.bak and the SL_OPEN_TARGET_DIRECTORY flag set which I believe is what I should expect and I pass it to FltCreateFileEx in this form.
In my IRP_MJ_SET_INFORMATION pre-handler, I replace Data->Iopb->TargetFileObject with its ‘lower’ FO and Data->Iopb->Parameters.SetFileInformation.ParentOfTarget with its ‘lower’ FO then FltSetCallbackDataDirty.
The root directory in the rename info is NULL.
The result in #10 is that I still get access denied, even though my parent and child objects were successfully created and swapped in when the FileRenameInformation came through.
So my question is why is the rename still returning access denied when the file objects appear to have been successfully created and swapped over?
Is there another check below my driver that maybe causing this? Do I need to impersonate? Or is there something about the FileRenameInformation that I don’t understand?
Nothing obvious to me, if you’re performing equivalent opens and swapping the file object it should “just work.”
Can you reproduce this over FAT? That makes life easier because you can just look up where the error is coming from. If not, NTFS has status debugging that will at least help pinpoint the check that’s failing. Which version of the OS is running on the target?
and it looks like the underlying access check is performed by SeAccessCheckWithHint (called by TxfAccessCheck) CheckIndexForAddOrDelete suggests that it’s checking access to the parent directory. Is there any way of finding out what the parameters are for these functions? The prototype for SeAccessCheck is out there, but not the newer ones.
I’m not sure I can reproduce the issue on FAT because I’m fixing up an ACCESS_DENIED.
Is there a way to get more logging from NTFS or SeAccessCheckWithHint so I can see which permissions it thinks I don’t have?
The parameters appear to contain an SD and a Token. The SD is from the parent directory which is OK but the Token looks like its from the standard user who I am trying to allow access to. Why would the filesystem need to perform another access check when access to the two file objects has already been checked and granted?