// используем IAccessControl

0);

assert(SUCCEEDED(hr));

то от пользователей, не имеющих 'x' в именах своих учетных записей, никакие поступающие вызовы не будут приняты. Поскольку имя опекуна содержит в качестве префикса имя домена, этот простой тест также предоставит доступ учетным записям пользователей, принадлежащих к доменам, содержащим 'x' в своих именах. Хотя этот тест доступа вряд ли будет слишком полезен, он демонстрирует технологию использования специального объекта IAccessControl с CoInitializeSecurity.

Под Windows NT каждый процесс имеет маркер доступа (access token), представляющий полномочия принципала защиты. Этот маркер доступа создается во время инициализации процесса и содержит различные виды информации о пользователе, в том числе его идентификатор защиты NT (SID), список групп, к которым принадлежит пользователь, а также список привилегий, которыми он обладает (например, может ли пользователь прекращать работу системы, может ли он менять значение системных часов). Когда процесс пытается получить доступ к ресурсам ядра безопасности (например, к файлам, ключам реестра, семафорам), контрольный монитор защиты NT (SRM – Security Reference Monitor) использует маркер вызывающей программы в целях аудита (отслеживания действий пользователей путем записи в журнал безопасности выбранных типов событий безопасности) и контроля доступа.

Когда в процесс поступает сообщение об ORPC-запросе, COM организует выполнение вызова соответствующего метода или в RPC-потоке (в случае объектов, расположенных в МТА), или в потоке, созданном пользователем (в случае объектов, расположенных в STA). В любом случае метод выполняется с использованием маркера доступа, соответствующего данному процессу. В целом этого достаточно, так как это позволяет разработчикам объекта прогнозировать, какие привилегии и права будут иметь их объекты, независимо от того, какой пользователь осуществляет запрос. В то же время иногда бывает полезно, чтобы метод выполнялся с использованием прав доступа клиента, вызывающего метод; чтобы можно было либо ограничить, либо усилить обычные права и привилегии объекта. Для поддержки такого стиля программирования в Windows NT допускается присвоение маркеров защиты отдельным потокам. Если поток имеет свой собственный маркер, контрольный монитор защиты не использует маркер процесса. Вместо него для выполнения аудита и контроля доступа используется маркер, присвоенный потоку. Хотя есть возможность программно создавать маркеры и присваивать их потокам, в COM предусмотрен гораздо более прямой механизм создания маркера на основе ORPC-запроса, обслуживаемого текущим потоком. Этот механизм раскрывается разработчикам объекта посредством контекстного объекта вызова, то есть вспомогательного объекта, который содержит информацию об операционном окружении серверного объекта.

Напоминаем, что контекстный объект вызова сопоставляется с потоком, когда ORPC-запрос направляется на интерфейсную заглушку. Разработчики объекта получают доступ к контексту вызова через API-функцию CoGetCallContext. Контекстный объект вызова реализует интерфейс IServerSecurity:

[local, object, uuid(0000013E-0000-0000-C000-000000000046)]

interface IServerSecurity : IUnknown {

// get caller's security settings

// получаем установки защиты вызывающей программы HRESULT

QueryBlanket(

[out] DWORD *pAuthnSvc, // authentication pkg

// модуль аутентификации

[out] DWORD *pAuthzSvc, // authorization pkg

// модуль авторизации

[out] OLECHAR **pServerName, // server principal

// серверный принципал

[out] DWORD *pAuthnLevel, // authentication level

// уровень аутентификации

[out] DWORD *pImpLevel, // impersonation level

// уровень заимствования прав

[out] void **pPrivs, // client principal

// клиентский принципал

[out] DWORD *pCaps // EOAC flags

// флаги EOAC

);

// start running with credentials of caller

// начинаем выполнение с полномочиями вызывающей программы

HRESULT ImpersonateClient(void);

// stop running with credentials of caller

// заканчиваем выполнение с полномочиями вызывающей программы

HRESULT RevertToSelf(void);

// test for impersonation

// проверка заимствования прав

BOOL IsImpersonating(void);

}

В одном из предыдущих разделов этой главы уже рассматривался метод QueryBlanket. Остальные три метода используются для управления маркерами потока во время выполнения метода. Метод ImpersonateClient создает маркер доступа, основанный на полномочиях клиента, и присваивает этот маркер текущему потоку. Как только возвращается IServerSecurity::ImpersonateClient, все попытки доступа к ресурсам операционной системы будут разрешаться или запрещаться в соответствии с полномочиями клиента, а не объекта. Метод RevertToSelf заставляет текущий процесс вернуться к использованию маркера доступа, принадлежащего процессу. Если текущий вызов метода заканчивает работу во время режима заимствования прав, то COM неявно вернет поток к использованию маркера процесса. И наконец, метод IServerSecurity::IsImpersonating показывает, что использует текущий поток: полномочия клиента или маркер процесса объекта. Подобно методу QueryBlanket, два метода IServerSecurity также имеют удобные оболочки, которые вызывают CoGetCallContext изнутри и затем вызывают соответствующий метод:

HRESULT CoImpersonateClient(void);

HRESULT CoRevertToSelf(void);

В общем случае, если будет использоваться более одного метода IServerSecurity, то эффективнее было бы вызвать CoGetCallContext один раз, а для вызова каждого метода использовать результирующий интерфейс IServerSecurity.

Следующий код демонстрирует использование контекстного объекта вызова для выполнения части кода метода с полномочиями клиента:

STDMETHODIMP MyClass::ReadWrite(DWORD dwNew, DWORD *pdw0ld)

{

// execute using server's token to let anyone read the value

// выполняем с использованием маркера сервера, чтобы

// все могли прочитать данное значение

ULONG cb;

HANDLE hfile = CreateFile(«C:\file1.bin», GENERIC_READ,

0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

if (hfile == INVALID_HANDLE_VALUE)