Столкнулся с проблемой:
Имеется драйвер-минифильтр. При внесении изменений на диск необходимо определять SID исполнителя (инициатора) изменений.

При запросах IRP_MJ_CREATE:

accessToken = SeQuerySubjectContextToken(&Data->Iopb->Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext);
SeQueryInformationToken(accessToken, TokenUser, &userToken);

для IRP_MJ_SET_INFORMATION:

accessToken = PsReferencePrimaryToken(PsGetCurrentProcess());
SeQueryInformationToken(accessToken, TokenUser, &userToken);

Собственно, проблема в том, что при удалении файлов/каталогов по сети, SID исполнителя всегда = System. А как узнать реального?

A>Собственно, проблема в том, что при удалении файлов/каталогов по сети, SID исполнителя всегда = System. А как узнать реального?
Вообще говоря, в NT принято проверять SID'ы при открытии объекта, сверять что запрошенный desired access разрешается, и валидировать доступ при последующих операциях над открытым объектом только используя granted access ассоциированный с уже открытым хэндлом.

Здравствуйте, ononim, Вы писали:

A>>Собственно, проблема в том, что при удалении файлов/каталогов по сети, SID исполнителя всегда = System. А как узнать реального?
O>Вообще говоря, в NT принято проверять SID'ы при открытии объекта, сверять что запрошенный desired access разрешается, и валидировать доступ при последующих операциях над открытым объектом только используя granted access ассоциированный с уже открытым хэндлом.


Т.е. держать в памяти карту всех открытых фалов и SID'ов, формируя её (карту) на IRP_MJ_CREATE и закрывая при IRP_MJ_CLOSE? Я правильно понял? И что является ключом карты в таком случае, PFILE_OBJECT?

A>Т.е. держать в памяти карту всех открытых фалов и SID'ов, формируя её (карту) на IRP_MJ_CREATE и закрывая при IRP_MJ_CLOSE? Я правильно понял? И что является ключом карты в таком случае, PFILE_OBJECT?
PFILE_OBJECT собственно и является.
А почему нельзя проверить desired access в обработчике IRP_MJ_CREATE и отрубить create, если реквестор запросит DELETE или GENERIC_ALL, если ваш драйвер решит что низзя и вернуть access denied именно оттуда? Это классическое поведение и проблем с ним со стороны 3rd parties будет меньше чем с отлупом SET_INFORMATION при успешно проделанном CREATE.

Здравствуйте, ononim, Вы писали:

O>PFILE_OBJECT собственно и является.
O>А почему нельзя проверить desired access в обработчике IRP_MJ_CREATE и отрубить create, если реквестор запросит DELETE или GENERIC_ALL, если ваш драйвер решит что низзя и вернуть access denied именно оттуда? Это классическое поведение и проблем с ним со стороны 3rd parties будет меньше чем с отлупом SET_INFORMATION при успешно проделанном CREATE.

Да мне, собственно, не нужно ничего отрубать, я только логирую. С картой, формируемой на IRP_MJ_CREATE, действительно все работает Спасибо!
Остался последний вопрос, есть ли разница, где именно собирать/очищать карту — на PreOperation или на PostOperation?

A>Да мне, собственно, не нужно ничего отрубать, я только логирую. С картой, формируемой на IRP_MJ_CREATE, действительно все работает Спасибо!
A>Остался последний вопрос, есть ли разница, где именно собирать/очищать карту — на PreOperation или на PostOperation?
лучше в PostOperation. ибо create ведь и зафэйлится может