Kernel mode Set Rename Information does not exist?

NTFSD
1

Dear Kernel Guru,

It seems that calling IRP_MJ_SET_INFORMATION with
Parameters.SetFile.FileInformationClass ==
FileRenameInformation does not allow “kernel mode” access to rename a file
object in NTFS.

I require the ability to rename (move or move/rename form with a FileObject
as the destination) preserving security from/to a location that is secure
and not accessible to the system process. I tried many different
permutations of setting security on the source and destination file (opened
with IO_OPEN_TARGET_DIRECTORY flag). I can’t find a combination that works,
short of compromising the integrity of the target directory (and the source
file) by adding LOCAL SYSTEM to the DACL of the target directory and the
source file. I can’t impersonate because I don’t have the SecurityContext
of that user at the time the move needs to take place.

Does anybody know how I might get around this limitation? I can create,
copy, and delete in kernel mode, but not RENAME. I don’t want to copy, as
this will not work unless enough free space exists for the destination file,
and it is very slow.

I thought of creating a target file, then making it link to the source
(FileLinkInformation) but I am not sure if security will be preserved (or
possibly setting links will not work in kernel mode either…) then deleting
the source file.

Any help would be much appreciated,
Kurt Godwin

2

You can very well rename in kernel mode. Give us the failure status code,
and maybe will see why it fails.

Dan

----- Original Message -----
From: “Kurt Godwin”
To: “File Systems Developers”
Sent: Tuesday, July 09, 2002 12:22 AM
Subject: [ntfsd] Kernel mode Set Rename Information does not exist?

> Dear Kernel Guru,
>
> It seems that calling IRP_MJ_SET_INFORMATION with
> Parameters.SetFile.FileInformationClass ==
> FileRenameInformation does not allow “kernel mode” access to rename a file
> object in NTFS.
>
> I require the ability to rename (move or move/rename form with a
FileObject
> as the destination) preserving security from/to a location that is secure
> and not accessible to the system process. I tried many different
> permutations of setting security on the source and destination file
(opened
> with IO_OPEN_TARGET_DIRECTORY flag). I can’t find a combination that
works,
> short of compromising the integrity of the target directory (and the
source
> file) by adding LOCAL SYSTEM to the DACL of the target directory and the
> source file. I can’t impersonate because I don’t have the SecurityContext
> of that user at the time the move needs to take place.
>
> Does anybody know how I might get around this limitation? I can create,
> copy, and delete in kernel mode, but not RENAME. I don’t want to copy, as
> this will not work unless enough free space exists for the destination
file,
> and it is very slow.
>
> I thought of creating a target file, then making it link to the source
> (FileLinkInformation) but I am not sure if security will be preserved (or
> possibly setting links will not work in kernel mode either…) then
deleting
> the source file.
>
> Any help would be much appreciated,
> Kurt Godwin
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>