NTKERNELAPI
NTSTATUS
SeQueryInformationToken (
IN PACCESS_TOKEN Token,
IN TOKEN_INFORMATION_CLASS TokenInformationClass,
OUT PVOID *TokenInformation
);
в данный момент я пользуюсь именно им.. на irp_create получаю сид — запоминаю его в своем map-e, а потом использую по необходимости...
Здравствуйте, Canavaro, Вы писали:
C>Здравствуйте, Valerio, Вы писали:
V>>надо разбираться — возможно просто неправильно получен SID в ядре, может быть это LogonID у Вас? V>>попробуйте с помощью разных программ в user mode получить то же самое для своих процессов — чей SID с ними ассоциирован через токен?
C>попробовал и получил совершено нормальный well-known Administartor SID S-1-5-21-1801674531-1957994488-842925246-500
значит ошибка у Вас
плюс прислушайтесь к _cb_: вытягивайте SID только в CREATE
во-вторых он правильно спросил в completion или нет Вы вытягиваете инфу: если в стеке есть хитрый драйвер вроде одной из версии NAV, то он может запросто переключить контекст на свой поток и Вы получите SID немного не тот... но в любом случае не такой странный, ИМХО
... << RSDN@Home 1.1.3 beta 1 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, _cb_, Вы писали:
__>на сколько я помню все проверки безопасности рекомендуется делать на irp_mj_create, а потом если Вам нужно знать какой пользователь посылает read, write и прочие запросы необходимо реализовать свой кеш открытых объектов. т.е на irp_mj_create получаете всю необходимую инфу и сохраняете ее в map-е где в качестве ключа используется file_object & fs_context, и при получении запросов ищете эту инфу в этом мапе...
если можно, то расскажите пожалуйста поподробнее про этот механизм, хотя бы в сторону каких функций копать.
Заранее спасибо!
Здравствуйте, Canavaro, Вы писали:
__>>на сколько я помню все проверки безопасности рекомендуется делать на irp_mj_create, а потом если Вам нужно знать какой пользователь посылает read, write и прочие запросы необходимо реализовать свой кеш открытых объектов. т.е на irp_mj_create получаете всю необходимую инфу и сохраняете ее в map-е где в качестве ключа используется file_object & fs_context, и при получении запросов ищете эту инфу в этом мапе...
C>если можно, то расскажите пожалуйста поподробнее про этот механизм, хотя бы в сторону каких функций копать. C>Заранее спасибо!
рассказать про что именно?
— про механизм создания кеша открытых объектов?
— или про то как правильно помещать в кеш объекты и когда их оттуда удалять?
про первый пункт — здесь Вы ограничены только своей изобретательностью:
Вам надо так или иначе сохранять свои данные и ассоциировать их с каким-то ключем. ключ вы однозначно получаете из самого irp-а (в данном случае в качестве ключа используется указатель на FileObject и указатель на FsContext), после получения ключа Вы просто ищете в своем кеше данные которые с этим ключем ассоциированы.
в stl есть готовая реализация подобной структуры — map. однако использование stl при разработки драйверов затруднено (хотя и возможно), поэтому скорее всего Вам придется придумать свой способ хранения этой информации...
Здравствуйте, _cb_, Вы писали:
__>Вам надо так или иначе сохранять свои данные и ассоциировать их с каким-то ключем. ключ вы однозначно получаете из самого irp-а (в данном случае в качестве ключа используется указатель на FileObject и указатель на FsContext), после получения ключа Вы просто ищете в своем кеше данные которые с этим ключем ассоциированы.
странно как то получается, но у меня на IRP_MJ_CREATE PtrCurrentStackLocation->FileObject->FsContext равно нулю ...
Здравствуйте, Canavaro, Вы писали:
C>Здравствуйте, _cb_, Вы писали:
__>>Вам надо так или иначе сохранять свои данные и ассоциировать их с каким-то ключем. ключ вы однозначно получаете из самого irp-а (в данном случае в качестве ключа используется указатель на FileObject и указатель на FsContext), после получения ключа Вы просто ищете в своем кеше данные которые с этим ключем ассоциированы.
C>странно как то получается, но у меня на IRP_MJ_CREATE PtrCurrentStackLocation->FileObject->FsContext равно нулю ...
В какой момент? до исполнения IRP_MJ_CREATE?
если до — то это правильно, потому что FsContext заполняется драйвером файловой системы в случае успешного открытия файла...
Здравствуйте, _cb_, Вы писали:
__>В какой момент? до исполнения IRP_MJ_CREATE? __>если до — то это правильно, потому что FsContext заполняется драйвером файловой системы в случае успешного открытия файла...
точно ДО !!!
Заранее прошу прощения за вероятно глупый вопрос, но как мне после того как я слепил IRP и послал его дальше драйверу файловой системы [IoCallDriver(PtrTargetDeviceObject, Irp)] получить FsContext ?
Здравствуйте, Canavaro, Вы писали:
C>точно ДО !!! C>Заранее прошу прощения за вероятно глупый вопрос, но как мне после того как я слепил IRP и послал его дальше драйверу файловой системы [IoCallDriver(PtrTargetDeviceObject, Irp)] получить FsContext ?
C>
после вызова IoCallDriver IRP скорее всего станет невалидным, потому что IRP_MJ_CREATE выполняется синхронно.
поэтому видимо проще запомнить указатель на FILE_OBJECT, а после вызова драйвера файловой системы и успешного открытия файла проверить поле FsContext.
Здравствуйте, _cb_, Вы писали:
__>после вызова IoCallDriver IRP скорее всего станет невалидным, потому что IRP_MJ_CREATE выполняется синхронно. __>поэтому видимо проще запомнить указатель на FILE_OBJECT, а после вызова драйвера файловой системы и успешного открытия файла проверить поле FsContext.
так работает, но есть одно "НО":
в качестве ключа как вы и говорили у меня выступает :
но при получении IRP_MJ_CREATE для одного и того же объекта файловой системы, одним и тем же процессом от имени одного и того же пользователя значение pr_key разное ... прочём разные получаются значения (DWORD)FileObjectа, а FsContext не меняется ... Может ли это означать что в такой маленький промежуток времени какой прошёл между обращениями, этот объет мог быть закрыт и открыт заново ?
Здравствуйте, Canavaro, Вы писали:
C>Здравствуйте, _cb_, Вы писали:
C>так работает, но есть одно "НО": C>в качестве ключа как вы и говорили у меня выступает :
C>DWORD pr_key = (DWORD)FileObject & (DWORD)FileObject;
здесь видимо имеется ввиду ((DWORD)FileObject & (DWORD)FsContext)?
сорри что ввел в заблуждение... я не имел ввиду буквально операцию AND.
я имел ввиду что в Вашем хранилище должен быть быть учет обоих ключей (FileObject и FsContext). дело в том что некоторые FileObject создаются системой без посылки IRP_MJ_CREATE. такие FO ссылаются на реально открытый объект посредством FsContext, который совпадает с FsContext-ом реально открытого объекта. поэтому поиск в кеше можно делать как по FileObject так и по FsContext. но это всего лишь один из вариантов реализации кеша. Вы можете придумать свой.
я уже давал ссылку на статью в osr — где описываются алгоритмы построения кеша открытых объектов, там это сделано более грамотно чем я могу это изложить...
C>но при получении IRP_MJ_CREATE для одного и того же объекта файловой системы, одним и тем же процессом от имени одного и того же пользователя значение pr_key разное ... прочём разные получаются значения (DWORD)FileObjectа, а FsContext не меняется ... Может ли это означать что в такой маленький промежуток времени какой прошёл между обращениями, этот объет мог быть закрыт и открыт заново ?
а вот этот пункт мне не очень понятен. раз Вы получили IRP_MJ_CREATE то это означает что происходит повторное открытие объекта. а вот должен ли при этом открытии поменяться FsContext видимо зависит от реализации FSD. возможно что для одного объекта файловой системы при повторном открытии не создается новый fs context, хотя мне лично это кажется маловероятным.
к сожалению тут я ничем помочь не могу — надо исследовать, я с этим не сталкивался.
__>я уже давал ссылку на статью в osr — где описываются алгоритмы построения кеша открытых объектов, там это сделано более грамотно чем я могу это изложить...
__>http://www.osr.com/ntinsider/2002/tracking/tracking.htm
мои 5 копеек, там есть псевдокод и была опечатка в конце статьи ставящяя все с ног на голову, be ready
C>>но при получении IRP_MJ_CREATE для одного и того же объекта файловой системы, одним и тем же процессом от имени одного и того же пользователя значение pr_key разное ... прочём разные получаются значения (DWORD)FileObjectа, а FsContext не меняется ... Может ли это означать что в такой маленький промежуток времени какой прошёл между обращениями, этот объет мог быть закрыт и открыт заново ?
__>а вот этот пункт мне не очень понятен. раз Вы получили IRP_MJ_CREATE то это означает что происходит повторное открытие объекта. а вот должен ли при этом открытии поменяться FsContext видимо зависит от реализации FSD. возможно что для одного объекта файловой системы при повторном открытии не создается новый fs context, хотя мне лично это кажется маловероятным. __>к сожалению тут я ничем помочь не могу — надо исследовать, я с этим не сталкивался.
с одного FCB (FsContext) свисает много FileObject. Например 2 экземпляра одного файла дадут Вам такое дело. Такое поведение FsContext действительно забота писателя FSD, но сейчас оно гарантируется для локальных FSD, поставляемых с ОС. Сетевые FSD (редиректоры) этого уже не гарантируют хотя LanMan redirector пока соответствует.
__>cb.
... << RSDN@Home 1.1.3 beta 1 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
__>после вызова IoCallDriver IRP скорее всего станет невалидным, потому что IRP_MJ_CREATE выполняется синхронно. __>поэтому видимо проще запомнить указатель на FILE_OBJECT, а после вызова драйвера файловой системы и успешного открытия файла проверить поле FsContext.
но тогда получается, что после проверки имени файла и DesiredAccess я не смогу зарубить IRP_MJ_CREATE ...
или можно ещё каким способом узнать имя файла, ведь перед посылкой запроса на открытие к драйверу файловой системы где-то должно храниться имя открываемого объкта ...
Здравствуйте, Canavaro, Вы писали:
__>>после вызова IoCallDriver IRP скорее всего станет невалидным, потому что IRP_MJ_CREATE выполняется синхронно. __>>поэтому видимо проще запомнить указатель на FILE_OBJECT, а после вызова драйвера файловой системы и успешного открытия файла проверить поле FsContext.
C>но тогда получается, что после проверки имени файла и DesiredAccess я не смогу зарубить IRP_MJ_CREATE ... C>или можно ещё каким способом узнать имя файла, ведь перед посылкой запроса на открытие к драйверу файловой системы где-то должно храниться имя открываемого объкта ...
вот здесь описано как сделать cancel irp_mj_create
про получение имени до выполнения открытия объекта могу сказать, что это достаточно сложная процедура, плюс не дающая 100% гарантии получения верного результата. я бы не рекомендовал Вам идти этим путем. если Вы все же решите попробовать этот вариант, то напишите мне по почте — я вышлю Вам код, который я использовал для этого, или посмотрите ранние версии ifskit_2k\src\filesys\filter\filespy, там есть пример получения имени до выполнения irp_mj_create.
понятно ...
__>про получение имени до выполнения открытия объекта могу сказать, что это достаточно сложная процедура, плюс не дающая 100% гарантии получения верного результата. я бы не рекомендовал Вам идти этим путем. если Вы все же решите попробовать этот вариант, то напишите мне по почте — я вышлю Вам код, который я использовал для этого,
послал письмо, жду ответа ...
и ещё, читал в этом форуме что если в pIrpStack->Parameters.Create.Options установлен флаг FILE_OPEN_BY_FILE_ID, то файл открывается по FILE_ID и его как то можно преобразовать в имя файла ...
Здравствуйте, Аноним, Вы писали:
А>послал письмо, жду ответа ...
ок.
А>и ещё, читал в этом форуме что если в pIrpStack->Parameters.Create.Options установлен флаг FILE_OPEN_BY_FILE_ID, то файл открывается по FILE_ID и его как то можно преобразовать в имя файла ...
я слышал что у файла теоретически может не быть символического имени — есть только ID. реально я с таким не сталкивался. а преобразования как такового нет — можно получить информацию о файле, там и можно увидеть его символическое имя.
я так понял что IoCancelFileOpen() нужно использовать в CREATE CompletionRoutine, но опять тот же вопрос — к этому времени я буду знать имя файла ? Ведь наскока я понимаю управление ещё не вернётся в мой Dispatcher ...
Спрошу проще: можно ли при помощи IoCancelFileOpen() реализовать схему :
IoCallDriver(...);
if (!Check(FileObj->FileName))
{
CancelCreate();
return STATUS_UNSUCCESSFUL;
}
Здравствуйте, Аноним, Вы писали:
А>я так понял что IoCancelFileOpen() нужно использовать в CREATE CompletionRoutine, но опять тот же вопрос — к этому времени я буду знать имя файла ? Ведь наскока я понимаю управление ещё не вернётся в мой Dispatcher ...
имя можно получить и в completion routine. потому что irp_mj_create всегда выполняется на passive_level и является синхронной операцией.
А>Спрошу проще: можно ли при помощи IoCancelFileOpen() реализовать схему :
А>IoCallDriver(...); А>if (!Check(FileObj->FileName)) А>{ А>CancelCreate(); А>return STATUS_UNSUCCESSFUL; А>}
лично я IoCancelFileOpen не использовал поэтому точно не могу сказать где именно она должна вызываться. однако судя по документации описанный Вами сценарий вполне работоспособен, надо только не забыть изменить значение pIrp->IoStatus.Status на STATUS_UNSUCCESSFUL.
Здравствуйте, _cb_, Вы писали:
__>Здравствуйте, Аноним, Вы писали:
А>>я так понял что IoCancelFileOpen() нужно использовать в CREATE CompletionRoutine, но опять тот же вопрос — к этому времени я буду знать имя файла ? Ведь наскока я понимаю управление ещё не вернётся в мой Dispatcher ...
__>имя можно получить и в completion routine. потому что irp_mj_create всегда выполняется на passive_level и является синхронной операцией.
А>>Спрошу проще: можно ли при помощи IoCancelFileOpen() реализовать схему :
А>>IoCallDriver(...); А>>if (!Check(FileObj->FileName)) А>>{ А>>CancelCreate(); А>>return STATUS_UNSUCCESSFUL; А>>}
Не ясно как вы будете FileObj->FileName использовать после IoCallDriver — или FileObj->FileName эта ваша внутрення переменная и вы уже скопировали имя файла до вызова IoCallDriver ?
__>лично я IoCancelFileOpen не использовал поэтому точно не могу сказать где именно она должна вызываться. однако судя по документации описанный Вами сценарий вполне работоспособен, надо только не забыть изменить значение pIrp->IoStatus.Status на STATUS_UNSUCCESSFUL.
__>cb.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
А>и ещё, читал в этом форуме что если в pIrpStack->Parameters.Create.Options установлен флаг FILE_OPEN_BY_FILE_ID, то файл открывается по FILE_ID и его как то можно преобразовать в имя файла ...
точно так же, как и в случае короткого имени например — выполнить подзапрос на получение имени файла
... << RSDN@Home 1.1.3 beta 1 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
и была опечатка в конце статьи ставящяя все с ног на голову, be ready 
