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

Если величина, именованная DllSurrogate, существует, но пуста, то SCM запустит суррогатный процесс по умолчанию (dllhost.exe). Если именованная величина DllSurrogate существует, но ссылается на легальное имя файла:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C7392SBA}] DllSurrogate="С:\somefile.exe"

то SCM запустит указанный серверный процесс. В любом случае суррогатный процесс саморегистрируется библиотекой COM (и SCM) с помощью API-функции CoRegisterSurrogate в качестве суррогатного процесса:

HRESULT CoRegisterSurrogate([in] ISurrogate *psg);

Эта API-функция предполагает, что суррогатный процесс предоставляет реализацию интерфейса ISurrogate:

[uuid(00000022-0000-0000-C000-000000000046), object] interface ISurrogate : IUnknown {

// SCM asking surrogate to load inprocess class object and

// call CoRegisterClassObject using REGCLS_SUSPENDED

// SCM просит суррогат загрузить внутрипроцессный

// объект класса и вызвать CoRegisterClassObject

// с флагом REGCLS_SUSPENDED

HRESULT LoadDllServer([in] REFCLSID rclsid);

// SCM asking surrogate to shut down

// SCM просит суррогат прекратить работу

HRESULT FreeSurrogate();

}

Интерфейс ISurrogate предоставляет COM механизм запроса суррогатного процесса для регистрации объектов класса с последующим его остановом. Суррогатный механизм существует в первую очередь для поддержки удаленной активации старых внутрипроцессных серверов. В общем случае суррогаты могли бы использоваться только в тех случаях, когда внутрипроцесные серверы не могут быть перестроены во внепроцессные.

Если, наконец, не существует ни одного из этих ключей реестра или именованных величин, то SCM будет искать элемент RemoteServerName под ключом AppID, соответствующим классу:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8CSF-0080C7392SBA}] RemoteServerName="www.apes.com"

При наличии этой величины активационный запрос будет переадресован SCM указанной хост-машины. Отметим, что даже если клиент указал в начальном запросе на активацию только флаг CLSCTX_LOCAL_SERVER, то запрос будет переадресован только в случае, если не зарегистрировано ни одного локального серверного процесса.

Еще один дополнительный фактор, способный изменить адресацию активационных запросов, относится только к запросам CoGetInstanceFromFile (включая вызовы BindToObject файлового моникера). По умолчанию, если имя файла, использованное для наименования постоянного объекта, относится к файлу из удаленной файловой системы, то COM будет использовать вышеописанный алгоритм для определения того, где активировать объект. Если, однако, AppID класса имеет именованную величину ActivateAtStorage и эта величина равна "Y" или "y", то COM направит активационный запрос к той машине, на которой располагается файл, при условии, что вызывающий объект не передавал явное хост-имя через структуру COSERVERINFO. Этот способ гарантирует, что во всей сети будет существовать только один экземпляр.

COM и защита

Исходная версия COM не занималась проблемой защиты. Это можно рассматривать как упущение, так как многие примитивы NT без удаленного доступа (nonremotable) (например, процессы, потоки) могут быть защищены, несмотря на то, что ими нельзя управлять дистанционно. Версия Windows NT 4.0 вынудила добавить к COM обеспечение безопасности, так как стало возможным осуществлять доступ к серверным процессам практически от любой машины в сети. К счастью, поскольку COM использует в качестве средства сообщения RPC, то защита COM просто применяет существующую инфраструктуру защиты RPC.

Защита COM может быть разделена на три категории: аутентификация (authentication), контроль доступа (access control) и управление маркерами (token management). Аутентификация заключается в обеспечении подлинности сообщения, а именно: отправитель действительно тот, за кого он себя выдает, а данное сообщение действительно пришло от отправителя. Контроль за доступом проверяет, кто имеет допуск к объектам сервера и кто имеет право запуска серверного процесса. Управление маркерами осуществляет контроль за тем, чьи полномочия использованы при запуске серверных процессов и при выполнении самого вызова метода. В COM предусмотрены до некоторой степени разумные установки по умолчанию по всем трем аспектам защиты, что делает теоретически возможным писать приложения COM, не учитывая вопросов безопасности. Эти установки по умолчанию основаны на принципе наименьших сюрпризов; то есть если программист не делает ничего явного по защите, то маловероятно, что этим будут внесены какие-либо «дыры» в систему безопасности NT. В то же время построение даже простейшего рассредоточенного приложения на базе COM требует, чтобы каждому аспекту обеспечения безопасности было уделено определенное внимание.