Сущность технологии СОМ. Библиотека программиста

typedef struct _ACTRL_ACCESS_ENTRY_LISTW {

ULONG cEntries;

[size_is(cEntries)] ACTRL_ACCESS_ENTRYW *pAccessList;

} ACTRL_ACCESS_ENTRY_LISTW, *PACTRL_ACCESS_ENTRY_LISTW;

И наконец, в Win32 предусмотрено еще два дополнительных типа данных, которые позволяют связывать элементы списков доступа с именованными признаками.

typedef struct _ACTRL_PROPERTY_ENTRYW {

LPWSTR lpProperty; // not used by COM

// не используется в COM

ACTRL_ACCESS_ENTRY_LISW *pAccessEntryList;

ULONG fListFlags; // not used by COM

// не используется в COM

} ACTRL_PROPERTY_ENTRYW, *PACTRL_PROPERTY_ENTRYW;

typedef struct _ACTRL_ALISTW {

ULONG cEntries;

[size_is(cEntries)]

ACTRL_PROPERTY_ENTRYW *pPropertyAccessList;

} ACTRL_ACCESSW, *PACTRL_ACCESSW;

Хотя в настоящее время COM не использует возможности контроля по каждому признаку, заключенному в этих двух типах данных, тип данных ACTRL_ACCESSW все же используется в интерфейсе IAccessControl для представления списков контроля доступа. Дело в том, что этот интерфейс широко используется также в службе директорий Windows NT 5.0, где требуется контроль доступа по каждому признаку.

В COM предусмотрена реализация интерфейса IAccessControl (CLSID_DCOMAccessControl), которую вызывающие программы могут заполнять явными именами учетных записей и правами доступа, используя типы данных контроля доступа NT 4.0[1]. Следующий фрагмент кода использует эту реализацию для создания объекта контроля доступа, разрешающего доступ для встроенной учетной записи SYSTEM и для пользователей в группе Sales\Managers, но запрещающего доступ для отдельного пользователя Sales\Bob:

HRESULT CreateAccessControl(IAccessControl * &rpac)

{

rpac = 0;

// create default access control object

// создаем объект контроля доступа по умолчанию

HRESULT hr = CoCreateInstance(CLSID_DCOMAccessControl,

0, CLSCTX_ALL, IID_IaccessControl,

(void**)&rpac);

if (SUCCEEDED(hr)) {

// build list of users/rights using NT4 security data types

// создаем списов пользователей/прав, используя типы данных защиты из NT4

ACTRL_ACCESS_ENTRYW rgaae[] = {

{ { 0, NO_MULTIPLE_TRUSTEE, TRUSTEE_IS_NAME,

TRUSTEE_IS_USER, L"Sales\\Bob" },

ACTRL_ACCESS_DENIED, COM_RIGHTS_EXECUTE, 0,

NO_INHERITANCE, 0 },

{ { 0, NO_MULTIPLE_TRUSTEE, TRUSTEE_IS_NAME,

TRUSTEE_IS_GROUP, L"Sales\\Managers" },

ACTRL_ACCESS_ALLOWED, COM_RIGHTS_EXECUTE, 0,

NO_INHERITANCE, 0 },

{ { 0, NO_MULTIPLE_TRUSTEE, TRUSTEE_IS_NAME,

TRUSTEE_IS_USER, L"NT AUTHORITY\\SYSTEM" },

ACTRL_ACCESS_ALLOWED, COM_RIGHTS_EXECUTE, 0,

NO_INHERITANCE, 0 }

};

ACTRL_ACCESS_ENTRY_LISTW aael =

{ sizeof(rgaae)/sizeof(*rgaae), rgaae };

ACTRL_PROPERTY_ENTRYW ape = { 0, &aael, 0 };

ACTRL_ACCESSW aa = { 1, &ape };

// present list of users+rights to Access Control object

// представляем список пользователей + прав объекту контроля доступа

hr = rpac->SetAccessRights(&aa);

}

return hr;

}

Имея эту функцию, приложение может связать вновь созданный объект контроля доступа с его процессом следующим образом:

IAccessControl *pac = 0;

HRESULT hr = CreateAccessControl(pac);

assert(SUCCEEDED(hr));

hr = CoInitializeSecurity(pac, -1, 0, 0,

RPC_C_AUTHN_LEVEL_PKT, RPC_C_IMP_LEVEL_IDENTIFY, 0,

EOAC_ACCESS_CONTROL,

// use IAccessControl

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

0);

assert(SUCCEEDED(hr));

pac->Release();

// COM holds reference until last CoUninitialize

// COM сохраняет ссылку до последнего CoUninitialize

Флаг EOAC_ACCESS_CONTROL показывает, что первый параметр в функции СоInitializeSecurity является указателем на интерфейс IAccessControl, а не указателем на SECURITY_DESCRIPTOR NT. При каждом поступающем запросе на связь COM будет использовать метод этого объекта IsAccessAllowed для определения того, разрешен или запрещен доступ к объектам процесса. Отметим, что хотя этот код должен исполняться до первого интересного вызова COM, вызов CoCreateInstance для получения реализации по умолчанию IAccessControl является допустимым, так как COM не рассматривает его как интересный.

Если список авторизованных пользователей не может быть известен во время запуска процесса, то можно зарегистрировать специальную (custom) реализацию IAccessControl, которая выполняет определенного рода проверку доступа во время выполнения в своей реализации метода IsAccessAllowed. Поскольку сама COM использует только метод IsAccessAllowed, то такая специальная реализация могла бы безошибочно возвращать E_NOTIMPL для всех других методов IAccessControl. Ниже приведена простая реализация IAccessControl, позволяющая получить доступ к объектам процесса только пользователям с символом "x" в именах своих учетных записей:

class XOnly : public IAccessControl {

// Unknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID riid, void **ppv) {

if (riid == IID_IAccessControl || riid == IID_IUnknown)

*ppv = static_cast(this);

else

return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

STDMETHODIMP_(ULONG) AddRef(void) { return 2; }

STDMETHODIMP_(ULONG) Release(void) { return 1; }

// IAccessControl methods

// методы IAccessControl

STDMETHODIMP GrantAccessRights(ACTRL_ACCESSW *)

{ return E_NOTIMPL; }

STDMETHODIMP SetAccessRights(ACTRL_ACCESSW *)

{ return E_NOTIMPL; }

STDMETHODIMP SetOwner(PTRUSTEEW, PTRUSTEEW)

{ return E_NOTIMPL; }

STDMETHODIMP RevokeAccessRights(LPWSTR, ULONG, TRUSTEEW[])

{ return E_NOTIMPL; }

STDMETHODIMP GetAllAccessRights(LPWSTR, PACTRL_ACCESSW_ALLOCATE_ALL_NODES *,

PTRUSTEEW *, PTRUSTEEW *)

{ return E_NOTIMPL; }

// this is the only IAccessControl method called by COM

// это единственный метод IAccessControl, вызванный COM

STDMETHODIMP IsAccessAllowed(

PTRUSTEEW pTrustee,

LPWSTR lpProperty,

ACCESS_RIGHTS AccessRights,

BOOL *pbIsAllowed)

{

// verify that trustee contains a string

// удостоверяемся, что опекун содержит строку

if (pTrustee == 0 || pTrustee->TrusteeForm != TRUSTEE_IS_NAME)

return E_UNEXPECTED;

// look for X or x and grant/deny based on presence

// ищем "X" или "x" и в зависимости от его наличия

// предоставляем или запрещаем

*pbIsAllowed = wcsstr(pTrustee->ptstrName, L"x") != 0 ||

wcsstr(pTrustee->ptstrName, L"X") != 0;

return S_OK;

}

}

Если экземпляр вышеприведенного класса C++ зарегистрирован c CoInitializeSecurity:

XOnly xo;

// declare an instance of the C++ class

// объявляем экземпляр класса C++

hr = CoInitializeSecurity(static_cast(&xo),

–1, 0, 0, RPC_C_AUTHN_LEVEL_PKT,

RPC_C_IMP_LEVEL_IDENTIFY, 0,

EOAC_ACCESS_CONTROL,

// use IAccessControl

// используем 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)

return MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, GetLastError());

ReadFile(hfile, pdwOld, sizeof(DWORD), &cb, 0);

CloseHandle(hfile);

// get call context object

// получаем контекстный объект вызова

IServerSecurlty *pss = 0;

HRESULT hr = CoGetCallContext(IID_IServerSecurity, (void**)&pss);

if (FAILED(hr)) return hr;

// set thread token to use caller's credentials

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

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

hr = pss->ImpersonateClient();

assert(SUCCEEDED(hr));

// execute using client's token to let only users that can

// write to the file change the value

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

// изменять это значение могли только те пользователи,

// которые имеют право записывать в файл

hfile = CreateFile(«C:\\file2.bin»,

GENERIC_READ | GENERIC_WRITE, 0, 0,

OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

if (hfile == INVALID_HANDLE_VALUE)

hr = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, GetLastError());

else {

WriteFile(hfile, &dwNew, sizeof(DWORD), &cb, 0);

CloseHandle(hfile);

}

// restore thread to use process-level token

// восстанавливаем режим использования потоком маркера процесса

pss->RevertToSelf();

// release call context

// освобождаем контекст вызова

pss->Release();

return hr;

}

Отметим, что первый вызов CreateFile выполняется с использованием полномочий процесса объекта, в то время как второй вызов – с полномочиями клиента. Если клиент имеет права доступа для чтения/записи в соответствующий файл, то второй вызов метода CreateFile может быть успешным, даже если обычно процесс объекта не имеет доступа к этому файлу.

Важно, что хотя методы IServerSecurity::ImpersonateClient всегда достигают цели, исключая катастрофический сбой, клиент объекта контролирует уровень заимствования прав, допускаемый результирующим маркером. Каждый интерфейсный заместитель имеет свой уровень заимствования прав, который должен быть равным одной из четырех констант (RPC_C_IMP_LEVEL_ANONYMOUS, RPC_C_IMP_LEVEL_IDENTIFY, RPC_C_IMP_LEVEL_IMPERSONATE или RPC_C_IMP_LEVEL_DELEGATE). Во время демаршалинга COM устанавливает этот уровень равным величине, определенной в клиентском вызове CoInitializeSecurity; однако данная установка может быть изменена вручную с помощью IClientSecurity::SetBlanket. Когда объект вызывает IServerSecurity::ImpersonateClient, новый маркер будет ограничен уровнем, заданном в интерфейсном заместителе, который использовался в данном вызове. Это означает, что если клиент задал только уровень RPC_C_IMP_LEVEL_IDENTIFY, то объект не может получить доступ к ресурсам ядра во время выполнения с полномочиями клиента. Объект, однако, может применить API-функции Win32 OpenThreadToken или GetTokenInformation для чтения информации о клиенте (например, ID защиты, групповое членство) из маркера режима анонимного воплощения (impersonation token). Важно отметить, что пока клиент не задал уровень RPC_C_IMP_LEVEL_DELEGATE, объект не может получить доступ ни к одному из удаленных ресурсов защиты, используя полномочия клиента. В их число входят открытие файлов в удаленной файловой системе, а также выполнение аутентифицированных COM-вызовов к удаленным объектам. К сожалению, протокол аутентификации NTLM не поддерживает уровень RPC_C_IMP_LEVEL_DELEGATE, так что под Windows NT 4.0 делегирование невозможно.

Во время предыдущего обсуждения акцент делался на том, что в нормальном режиме методы объекта выполняются с использованием маркера доступа процесса объекта. Однако не обсуждался вопрос о том, как проконтролировать, какой принципал защиты должен использоваться для создания начального маркера серверного процесса. Когда SCM запускает серверный процесс, то он присваивает новому серверному процессу маркер, основанный на конфигурации именованной величины RunAs из AppID. Если же в AppID нет величины RunAs, то считается, что сервер неправильно сконфигурирован для работы в режиме распределенного доступа. Для того чтобы этот тип серверного процесса не внедрял указанные «дыры» в защите в систему, SCM запускает такие процессы с использованием того принципала защиты, который произвел запрос на активацию. Такой тип активации часто называют активацией «как активизатор» («As Activator»), так как серверный процесс выполняет тот же принципал защиты, что и запускающий пользователь. Активация типа «как активизатор» предназначена для поддержки удаленной активации старых серверов и содержит несколько ловушек. Во-первых, чтобы придерживаться семантики типа «как активизатор», COM запустит отдельный серверный процесс для каждой активационной учетной записи пользователя, независимо от того, используется ли REGCLS_MULTIPLEUSE в CoRegisterClassObject. Это вступает в серьезный конфликт с принципом расширяемости и вдобавок делает невозможным сохранение всех экземпляров класса в одном и том же процессе. Во-вторых, каждый серверный процесс запускается с маркером, ограниченным уровнем RPC_C_IMP_LEVEL_IMPERSONATE, из чего следует, что серверные процессы не имеют доступа ни к каким удаленным ресурсам или объектам[1].

В идеале серверные процессы конфигурируются для запуска как отдельные принципалы защиты. Управлять этим можно, помещая именованную величину RunAs в имя учетной записи в AppID:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]

RunAs="DomainX\UserY"

Если эта именованная величина присутствует, SCM будет использовать указанное имя учетной записи для создания нового регистрационного маркера (login token) и присвоит этот маркер серверному процессу. Для правильной работы этой схемы требуются два условия. Во-первых, соответствующий пароль должен быть записан в определенном месте реестра в качестве ключа локальных средств защиты (LSA – Local Security Authority). Во-вторых, указанная учетная запись пользователя должна иметь полномочия «Вход в систему как пакетное задание» («Logon as a batch job»). При установке значения RunAs утилита DCOMCNFG.EXE обеспечивает выполнение обоих этих условий[2].

Для предотвращения спуфинга (spoofing, получение доступа путем обмана) классов злонамеренными программами CoRegisterClassObject проверяет, зарегистрирован ли AppID данного класса. Если AppID имеет установку RunAs, то COM гарантирует, что принципал вызывающей программы совпадает с именем принципала, записанным в реестре. Если же вызывающая программа не имеет указанной учетной записи RunAs для AppID класса, то вызов метода CoRegisterСlassObject будет отклонен и возвратится известный HRESULT CO_E_WRONG_SERVER_IDENTITY. Поскольку конфигурационные установки COM записаны в защищенной части реестра, только привилегированные пользователи могут изменять список соответствия классов и пользователей.

Важно отметить, что когда в AppID имеется явная учетная запись пользователя RunAs, то SCM всегда будет запускать серверный процесс в его собственной отдельной window-станции (window station)[3]. Это означает, что серверный процесс не может с легкостью ни создавать окна, видимые для интерактивного пользователя на данной машине, ни принимать информацию с клавиатуры, от мыши или из буфера (clipboard). Вообще говоря, такая защита полезна, поскольку не дает простым (naive) серверам COM влиять на деятельность пользователя, работающего на машине[4]. К сожалению, иногда серверному процессу бывает необходимо связаться с авторизовавшимся (logged on) в данный момент пользователем. Одним из способов достижения этого является использование для управления window-станциями и рабочими столами (desktop) явных API-функций COM, что дает потоку возможность временно выполняться на интерактивном рабочем столе. При выполнении на интерактивном рабочем столе любые окна, которые создает поток, будут видимы интерактивному пользователю, и, кроме того, поток может получать аппаратные сообщения (hardware messages) от клавиатуры и мыши. Если же все, что нужно, – это получить от пользователя ответ типа да/нет, то на этот случай в API-функции Win32 MessageBox имеется флаг MB_SERVICE_NOTIFICATION, при выставлении которого, без какого-либо добавочного кода, на интерактивном рабочем столе появится окно сообщения.

Если требуется расширенное взаимодействие с интерактивным пользователем, то использование Win32 API window-станции может стать весьма громоздким. Лучшим подходом могло бы стать выделение компонентов пользовательского интерфейса во второй внепроцессный сервер, который сможет работать на window-станции, отличной от той, на который запущена основная иерархия объектов. Чтобы заставить серверный процесс, содержащий компоненты пользовательского интерфейса, работать при интерактивной пользовательской window-станции, COM распознает характерное значение RunAs «Interactive User» («Интерактивный пользователь»):

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]

RunAs="Interactive User"

При использовании этого значения COM запускает новый серверный процесс в window-станции, соответствующей подсоединенному в текущий момент пользователю. Для запроса полномочий для нового серверного процесса COM при создании этого нового серверного процесса просто копирует маркер текущего интерактивного сеанса. Это означает, что в реестр не требуется записывать никаких паролей. К сожалению, и этот режим активации не обходится без ловушек. Во-первых, если активационный запрос поступает в момент, когда на хост-машине не зарегистрировано ни одного пользователя, то активационный запрос даст сбой с результатом E_ACCESSDENIED. Кроме того, если интерактивный пользователь выйдет из сети в тот момент, когда у серверного процесса еще есть подключенные клиенты, то серверный процесс будет преждевременно прерван, что приведет к грубому отсоединению всех существующих в тот момент заместителей. И наконец, часто невозможно предсказать, какой пользователь будет подсоединен во время активации, что усложняет обеспечение достаточных прав и привилегий доступа ко всем необходимым ресурсам для данного объекта. Эти ограничения сводят применимость такого режима активации к простым компонентам пользовательского интерфейса[5].

Одна интересная разновидность управления маркером и window-станцией серверного процесса относится к службам NT. Напомним, что наличие именованной величины LocalService заставляет SCM использовать для запуска серверного процесса NT Service Control Manager вместо CreateProcess или CreateProcessAsUser. При запуске серверных процессов как сервисов NT COM не контролирует, с каким принципалом запускается этот процесс просто потому, что это жестко запрограммировано в конфигурации соответствующей запущенной службы NT. В этом случае COM игнорирует именованную величину RunAs, чтобы убедиться, что случайные процессы не могут имитировать вызовы CoRegisterClassObject. Наличие именованной величины LocalService требует, чтобы вызывающая программа выполнялась как сервис NT. Если сам этот сервис сконфигурирован на запуск как встроенная учетная запись SYSTEM, то серверный процесс либо запустит интерактивную window– станцию, либо будет запущена заранее определенная window-станция, совместно используемая всеми сервисами NT в качестве SYSTEM (это зависит от того, как именно сконфигурирован сервис NT). Если вместо этого сервис NT сконфигурирован для выполнения как отдельная учетная запись пользователя, то NT Service Control Manager будет всегда запускать сервис NT под новой window– станцией, специфической для данного серверного процесса.

Одно общее соображение в пользу реализации сервера COM как сервиса NT заключается в том, что только сервисы NT способны выполняться со встроенной учетной записью SYSTEM. Эта учетная запись обыкновенно имеет больший доступ к таким локальным ресурсам, как файлы и ключи реестра. Кроме того, эта учетная запись часто является единственной, которая может выступать как часть доверительной компьютерной базы (trusted computing base) и использовать низкоуровневые службы защиты, доступ к которым был бы опасен из обычных пользовательских учетных записей. К сожалению, хотя учетная запись SYSTEM воистину всемогуща в локальной системе, она полностью бессильна для доступа к защищенным удаленным ресурсам, в том числе к удаленным файловым системам и к удаленным объектам COM. Это обстоятельство делает учетную запись SYSTEM отчасти менее полезной для построения распределенных систем, чем можно было бы ожидать. Вне зависимости от того, используется ли сервер как сервис NT или в качестве традиционного процесса Win32, принято создавать отдельную учетную запись пользователя для каждого приложения COM, которое имеет полные полномочия для доступа в сеть.

Где мы находимся?

В данной главе рассматривались вопросы, относящиеся к выделению классов в отдельные серверные процессы. COM поддерживает запуск серверных процессов на основе запросов на активацию. Эти серверные процессы должны саморегистрироваться с помощью библиотеки COM, используя CoRegisterClassObject для того, чтобы обеспечить доступ к объектам своего класса со стороны внешних клиентов. Архитектура системы безопасности COM тесно связана с собственной моделью безопасности операционной системы и основывается на трех различных понятиях. Целостность и аутентичность сообщений ORPC, которыми обмениваются клиент и объект, обеспечивается аутентификацией. Контроль доступа выявляет, какие принципалы защиты могут иметь доступ к объектам, экспортированным из данного процесса. Управление маркерами отслеживает, какие полномочия используются для запуска серверных процессов и выполнения методов объекта.

Разное

IChapter *pc = 0;

HRESULT hr = CoGetObject(OLESTR(«Chapter:7»), О,

IID_IChapter, (void**)&pc);

if (SUCCEEDED(hr)) {

hr = pc->IncludeAllTopicsNotCoveredYet();

pc->Release(); }

Автор, 1997

В предыдущей главе были представлены основы модели программирования СОМ и архитектуры удаленного доступа. Различные интерфейсы и методики СОМ рассматриваются на протяжении всей книги. Однако осталось несколько вопросов, не связанных ни с какой определенной главой, о которых следует рассказать подробно. Вместо того чтобы просто втиснуть эти вопросы в другие главы, которые были скомпонованы рационально или даже превышали разумные размеры, я отвел данную главу под хранилище для «маленьких» тем, которые не всегда подходят к другим частям книги. За исключением вводных разделов об указателях, управлении памятью и массивах, ни одна из этих тем не является жизненно необходимой для создания эффективных распределенных систем с СОМ. Помните об этом и расслабьтесь, в то время как ваши глаза будут скользить вдоль строк этой главы.

Основы указателей

СОМ, подобно DCE (Distributed Computing Environment – среда распределенных вычислений), ведет свое начало от языка программирования С. Хотя лишь немногие разработчики используют С для создания или использования компонентов СОМ, именно от С СОМ унаследовала синтаксис для своего языка определений интерфейсов (Interface Definition Language – IDL). Одной из наиболее сложных проблем при разработке и использовании интерфейсов является управление указателями. Рассмотрим такое простое определение метода IDL:

HRESULT f([in] const short *ps);

Если бы вызывающая программа должна была запустить этот метод так:

short s = 10;

HRESULT hr = p->f(&s);

то величину 10 следовало бы послать объекту. Если бы этому методу нужно было выйти за границы апартамента, то интерфейсный заместитель был бы обязан разыменовать указатель и передать величину 10 в сообщение ORPC-запроса.

Следующий клиентский код, хотя и написан целиком в традициях С, представляет собой более интересный случай:

HRESULT hr = p->f(0);

// pass a null pointer