Is it OK to reference and dereference access token with
ObReferenceObject/ObDereferenceObject routines.
I’m currently working on FSFD for AV. After a file was closed, I need to
re-open it to check its contents. In IRP_MJ_CREATE dispatch routine I
reference access token passed in IRP. After file was closed I open access
token with ObOpenObjectByPointer in the context of the thread that wants to
re-open file. I use acquired token handle to impersonate re-opening thread.
The problem is that from time to time I get a BSOD (sometimes it needs
several minutes to bugcheck, sometimes it runs whole night before it
crushes). The reason is that access token is freed by the time I try to open
it with ObOpenObjectByPointer (WinDBG shows reference count == 0). Is my
approach fine and I need to look for erros in my sources (I already looked
my eyes to holes trying to find any errors), or perhaps I need a major
redesign?
Thanks in advance.
–htfv
I am not sure that it is safe.
At least there are special functions to deal with tokens -
PsReferencePrimary(Impersonation)Token and corresponding dereference
functions.
Also I used to impersonate threads in kernel using
SeCaptureSubjectContext/SeImpersonateClient that doesn’t require token
handle.
Alexei.
“Alexey Logachyov” wrote in message news:xxxxx@ntfsd…
> Is it OK to reference and dereference access token with
> ObReferenceObject/ObDereferenceObject routines.
>
> I’m currently working on FSFD for AV. After a file was closed, I need to
> re-open it to check its contents. In IRP_MJ_CREATE dispatch routine I
> reference access token passed in IRP. After file was closed I open access
> token with ObOpenObjectByPointer in the context of the thread that wants
to
> re-open file. I use acquired token handle to impersonate re-opening
thread.
>
> The problem is that from time to time I get a BSOD (sometimes it needs
> several minutes to bugcheck, sometimes it runs whole night before it
> crushes). The reason is that access token is freed by the time I try to
open
> it with ObOpenObjectByPointer (WinDBG shows reference count == 0). Is my
> approach fine and I need to look for erros in my sources (I already looked
> my eyes to holes trying to find any errors), or perhaps I need a major
> redesign?
>
> Thanks in advance.
>
> --htfv
>
>
>
>
>
I need to pass token handle to user-mode service. I cannot change this
behaviour. PsDereferencePrimary/ImpersonationToken are exported on Windows
XP and later OSes.
Perhaps I should try to duplicate token in my create dispatch routine
instead of referencing it, and see if the problem goes.
–htfv
“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
> I am not sure that it is safe.
> At least there are special functions to deal with tokens -
> PsReferencePrimary(Impersonation)Token and corresponding dereference
> functions.
> Also I used to impersonate threads in kernel using
> SeCaptureSubjectContext/SeImpersonateClient that doesn’t require token
> handle.
>
> Alexei.
>
> “Alexey Logachyov” wrote in message news:xxxxx@ntfsd…
> > Is it OK to reference and dereference access token with
> > ObReferenceObject/ObDereferenceObject routines.
> >
> > I’m currently working on FSFD for AV. After a file was closed, I need to
> > re-open it to check its contents. In IRP_MJ_CREATE dispatch routine I
> > reference access token passed in IRP. After file was closed I open
access
> > token with ObOpenObjectByPointer in the context of the thread that wants
> to
> > re-open file. I use acquired token handle to impersonate re-opening
> thread.
> >
> > The problem is that from time to time I get a BSOD (sometimes it needs
> > several minutes to bugcheck, sometimes it runs whole night before it
> > crushes). The reason is that access token is freed by the time I try to
> open
> > it with ObOpenObjectByPointer (WinDBG shows reference count == 0). Is my
> > approach fine and I need to look for erros in my sources (I already
looked
> > my eyes to holes trying to find any errors), or perhaps I need a major
> > redesign?
> >
> > Thanks in advance.
> >
> > --htfv
> >
> >
> >
> >
> >
>
>
>