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
> 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.
I don’t know what do you exactly want to do in paging I/O path,
but the only safe way how to deny something at file level is
pre-create path.
Moreover, impersonation in paging I/O path is not possible,
as paging I/Os run in the context of “System” user.
If you deny paging I/O, then be ready for a big mess in the OS,
beginning with dialogs “Delayed write failed” and ending with file
corruption.
L.
I think some additional information is needed, so it clarifies why we need impersonation. Our FSD uses cache which lays on the local FSD (ntfs). Cache is placed in user’s “Documents and settings/…/Local/Application data/…”. All what we need is support EFS when user switches it on.
-bg
Hi Ladislav,
Thanks for the answer.
I don’t know what do you exactly want to do in paging I/O path,
but the only safe way how to deny something at file level is
pre-create path.
I don’t want deny anything. We are FSD not FSF or mini-filter.
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.
If you deny paging I/O, then be ready for a big mess in the OS,
beginning with dialogs “Delayed write failed” and ending with file
corruption.
I hope we will not fail anything.
-bg