Hi all,
can anyone tell me if the FileHandle and/or File Object opened in the context of a User Process are still valid even after the process
in context of which they were opened, is terminated. I know that in Win32 space, if you leak a handle, it gets closed when the process terminates. Is it also valid for the handles/FileObjects opened in the User Process context, but in the kernel driver.
I am caching the FileHandles and FileObjects and I am worried that my model can fall apart if the cached FileHandle and FileObject
get removed from underneath of my driver.
Here is what I am actually trying to do:
I have to access the file located at a shared folder on network. Initially, the request comes in the User Context,
and therefore I do not have any problem accessing the remote location. But later, I may have to access that file
in the system context, and this creates a problem since I do not have proper privileges in the system context to access the
network file. I am following the approach described at the following URL to overcome this limitation:
http://www.pulsetrainsw.com/article1.htm
Basically, in the User Context, I open the file using ZwCreateFile, save the context using IoGetCurrentProcess,
and get the File Object using ObReferenceObjectByHandle. Later, if I am called in the same context, I just re-use already opened
FileHandle. If I am called in system context, I get the context FileHandle using the undocumented but widely used
ObOpenObjectByPointer API.
It is quite possible that I will receive a request in the System Context some time after the User Process terminates.
Thanks,
Ilya.
…
Ilya Levin
File System Developer
xxxxx@softricity.com
Softricity, Inc.
332 Congress Street
Boston, MA 02210
617.695.0336 x168
www.softricity.com - Powering Software as a Service
…
FileHandles are not valid once the process is closed. You can take an extra
reference on the object and keep the object alive. I am not sure why you
want to circumvent filesystem security ? Security is a policy issue. If the
administrator wants to give system access to a file he can do so. Kernel
code should not set policy or bypass administrator set policies.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Ilya Levin” wrote in message news:xxxxx@ntdev…
Hi all,
can anyone tell me if the FileHandle and/or File Object opened in the
context of a User Process are still valid even after the process
in context of which they were opened, is terminated. I know that in Win32
space, if you leak a handle, it gets closed when the process terminates. Is
it also valid for the handles/FileObjects opened in the User Process
context, but in the kernel driver.
I am caching the FileHandles and FileObjects and I am worried that my model
can fall apart if the cached FileHandle and FileObject
get removed from underneath of my driver.
Here is what I am actually trying to do:
I have to access the file located at a shared folder on network. Initially,
the request comes in the User Context,
and therefore I do not have any problem accessing the remote location. But
later, I may have to access that file
in the system context, and this creates a problem since I do not have proper
privileges in the system context to access the
network file. I am following the approach described at the following URL to
overcome this limitation:
http://www.pulsetrainsw.com/article1.htm
Basically, in the User Context, I open the file using ZwCreateFile, save the
context using IoGetCurrentProcess,
and get the File Object using ObReferenceObjectByHandle. Later, if I am
called in the same context, I just re-use already opened
FileHandle. If I am called in system context, I get the context FileHandle
using the undocumented but widely used
ObOpenObjectByPointer API.
It is quite possible that I will receive a request in the System Context
some time after the User Process terminates.
Thanks,
Ilya.
…
Ilya Levin
File System Developer
xxxxx@softricity.com
Softricity, Inc.
332 Congress Street
Boston, MA 02210
617.695.0336 x168
www.softricity.com - Powering Software as a Service
…