>> Moreover, impersonation in paging I/O path is not possible,
> as paging I/Os run in the context of “System” user.
Yes, system process is running under “local system” account, but it
shouldn’t prevent you from impersonating of system worker thread
running at passive level. Of course the impersonation must be
“reverted” before the I/O is completed. The impersonation token
should be stored somewhere in PETHREAD and is local for this thread.
Bah, sorry, I confuse impersonation and access validation,
it’s probably already too late for me 
You are right.
However, I am not sure if you need to do impersonation in
paging I/O path for the EFS needs. If you create an encrypted file
and then write to it, the paging I/O write for that file will
arrives in the context of System process as well, so NTFS must
handle it somehow.
L.
The security attributes of the thread in read/write path is just not
relevant.
Security attributes are only checked in MJ_CREATE, to answer the question
of “can I open this file with this DesiredAccess using my current credentials”?
FSDs are allowed - and do this extensively - to offload read/write
processing to the system thread without doing any impersonation.
So, the answer is - “do not bother impersonation in reads and writes”.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> Do paging I/Os (a mean read ahead, lazy writer and write behind) use always
“arbitrary” FILE_OBJECT? My concern is if I would save access token from IRP in
IRP_MJ_CREATE into CCB, can I later use it for impersonation in paging I/Os.
>
> According to documentation for SeImpersonateClientEx() the callers must be
running at IRQL_PASSIVE_LEVEL, so I plan process Paging I/O which comes at
APC_LEVEL in the worker thread. Are there any caveats? I know that there is a
special handling in IoCompleteRequest() for paging I/O reads, so it doesn’t use
APC. Can I get paging I/O writes at APC_LEVEL?
>
> For Asynchronous requests coming from user mode (other then IRP_MJ_CREATE):
Is good practice to use saved token from IRP_MJ_CREATE for impersonation or
should I use access token obtained from thread which is saved in IRP (arbitrary
thread which initiated operation) ?
>
> Thanks in andvance for clarification.
> Bronislav Gabrhelik
>
>
>
>
Maxim,
Thanks for the response.
The security attributes of the thread in read/write path is just not
relevant.
Security attributes are only checked in MJ_CREATE, to answer the question
of “can I open this file with this DesiredAccess using my current credentials”?
I am sorry but I didn’t describe for which purpose I am discussing impersonation, so it caused confusion I guess. Did you read my additional explanation? Let me clarify it. We are remote FSD. We use extensively local secondary storage in dispatch routines. Note that processing of write/read can generate one or more IRP_MJ_CREATE/S on secondary storage (of course we use API like ZwCreateFile() ). I know it is not optimal, but the core code in this driver remembers ages of win95 and nobody wants to touch it. You know: newer touch running system. Also it was not easy persuade management that we should start from the scratch. At this point we were finally successful, but we still need to improve the old stuff. When user maps drive it is visible only in his logon session. With this drive is associated secondary storage which is somewhere in user’s “Documents & settings”. What we need is to be able to use this secondary storage even if the user switches EFS encryption on on this secondary storage.
So, the answer is - “do not bother impersonation in reads and writes”.
Still do you think that we shouldn’t bother impersonation?
Thanks
-bg
>settings". What we need is to be able to use this secondary storage even if
the
user switches EFS encryption on on this secondary storage.
Looks like it can be OK to bother with impersonation only on opening the EFS
encrypted secondary file, not on reads and writes to it.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim,
thanks for the response.
It means that I need to do impersonation in Paging i/o path, so my original questions are still valid. Topic is at the edge of my knowledge. Is there an expert who is familiar with the topic?
I wonder if it is possible to get (synchronous) paging write at APC_LEVEL from system. Can I process such requests asynchronously? My concern is I/O completion which requires APC. Note that we don’t support paging file. We support only mapped files.
Here are my original questions.
According to documentation for SeImpersonateClientEx() the callers must be
running at IRQL_PASSIVE_LEVEL, so I plan process Paging I/O which comes at
APC_LEVEL in the worker thread. Are there any caveats? I know that there is a
special handling in IoCompleteRequest() for paging I/O reads, so it doesn’t use
APC. Can I get paging I/O writes at APC_LEVEL?
Thanks
-bg