minifilter setInformationFile rename issue

NTFSD
1

Hi, Experts:

I have the following question about the permission of the rename a file in
minifilter. As to my case again, I have my minifilter driver running on a
file server (win2003/win2008), the reparse-point file(stub) and the real
content file are located at the same directory on the file server. I am
trying to rename the real-content file to the name of the stub file with
the function setInformationFile(renameinformation) with the minifilter. So
when the user double click the stub file, the minifilter will rename the
content file to the stub file and the user can open the file and read the
content.

If the user login as a read-only user(read-only permission for the share
folder from the file server) from a client
machine(win7/winxp/win2003/win2008), and access the share folder (where the
stub file and content file located) from the file server. The minifiler
setInformationFile(renameinformation) will return status
0x00000022(ACCESS_DENIED). If the user login as a “full-control” or
“Modify” permission from the client, the rename will be successful. The
following is part of the code sample:

// try to open the content file, the content file is already in the
directory
status = FltCreateFile(HSMData.Filter, InstanceHandle, &FileHandle,
FILE_WRITE_ATTRIBUTES|STANDARD_RIGHTS_ALL, &ObjectAttributes,
&IoStatusBlock, NULL, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ|FILE_SHARE_WRITE, FILE_OPEN,
FILE_COMPLETE_IF_OPLOCKED, NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK);

if(NT_SUCCESS(status))
{
PFILE_OBJECT pFileObject;
status = ObReferenceObjectByHandle(FileHandle, 0, NULL, KernelMode,
&pFileObject, NULL);

if(NT_SUCCESS(status))
{
pRenameInfo = ExAllocatePool(NonPagedPool, sizeof(FILE_RENAME_INFORMATION)

  • nNewNameLen * 2);

if(pRenameInfo)
{
//rename the content file to stub
RtlZeroMemory(pRenameInfo, sizeof(FILE_RENAME_INFORMATION) + nNewNameLen *
2);
pRenameInfo->ReplaceIfExists = TRUE;
pRenameInfo->RootDirectory = NULL;
pRenameInfo->FileNameLength = nNewNameLen * 2;
RtlCopyMemory(pRenameInfo->FileName, pCur, nNewNameLen * 2);
<------------this is the stub file name
status = FltSetInformationFile(InstanceHandle, pFileObject, pRenameInfo,
sizeof(FILE_RENAME_INFORMATION) + nNewNameLen * 2 - 2,
FileRenameInformation); <-------------the rename may be ACCESS_DENIED for
read-only user
}
}
}

My question is:

  1. why the read-only user rename will fail? The minifilter is always
    running on the same file server as the stub file and the real content file.
    will the driver run with the same permissions as the client login user ? At
    least from the test result, it is yes, the “full control” or “Modify” user
    from the client can run the rename successfully. Forget to mention, the
    driver is loaded by my own application running as a service on the file
    server

  2. for the function FltCreateFile(), the parameter “ShareAccess”
    is FILE_SHARE_READ|FILE_SHARE_WRITE, I wonder if I should set it
    as FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, but I tried, and
    seems no difference for the client read-only user(rename still
    ACCESS_DENIDED)

  3. for the FltCreateFile(), if the parameter “flags”
    is IO_IGNORE_SHARE_ACCESS_CHECK, the “full control” and “Modify”
    permissions user from client can rename the file successfully, if the
    “flags” is IO_FORCE_ACCESS_CHECK, only the user with “full control”
    permissions from client can rename the file.

  4. which confuses me most, during my test, for some time (only some time),
    with the above FltCreate() function settings(and the same hardware
    environment), the read-only user can rename successfully from the content
    file to the stub file, I am investigating the problem.

Thanks !

2

I’d say it would be helpful to mention exactly which call fails. From your post it is unclear if it is the FltCreateFile() call that fails or the FltSetInformationFile() that fails.

Anyway, to answer your questions:

  1. As you have noticed, who the user is matters. It is therefore safe to assume that the access rights of the remote user play into this. I’m guessing that the read-only user doesn’t have the required permissions for rename (DELETE) and so your FltCreateFile() fails with STATUS_ACCESS_DENIED.

  2. In general if the sharing mode is incompatible with existing handles you’ll get a STATUS_SHARING_VIOLATION and not an STATUS_ACCESS_DENIED. So it makes sense that changing the sharing mode doesn’t change anything in your case.

  3. Please read the documentation for those flags. The approach of trying to set all possible combinations of flags is not going to work.

I’d say if you need to always be able to rename the file then you can’t run impersonating the current user so either create another user that you can impersonate to or run with a service and just post the rename requests to it (or something along those lines).

Thanks,
Alex.