COM взаимодействие службы Win32 и пользовательского приложения

← →
Note (2006-11-02 18:26) [0]

Добрый день, помогите прояснить ситуацию.

Предположим есть EXE-СOM сервер «объект1», и два COM клиента «объект2» и «обект3». Причём «объект2» является сервисом (службой Win32) и стартует при загрузке системы от имени SYSTEM (сразу скажу, что запуск от учётной записи какого-либо пользователя НЕ приемлем). Далее хочу, чтобы к «объекту1» могли подсоединяться как «объект2», так и «объект3» , причём так чтобы процесс «объект1» запускался в единственном экземпляре, т.е и «объект2» и «объект3» работали с одним и тем же «объектом1». Согласно описанию COM для этого необходимо выставить флаг ciMultiInstance при создании фабрики класса «объекта1» - так и делаю. Но в реале наблюдаю следующую ситуацию: служба «объект2» создаёт свой экземпляр (процесс) «объекта1» от имени SYSTEM, а «объект3» тоже свой, но от имени текущего пользователя. От сюда вопрос: как сделать так, чтобы процесс «объекта1» запускался в единственном экземпляре? Вначале подозревал, что всё дело из-за различия пользователей под которыми стартует служба («объект2» ) и «объект3», поэтому принудительно указал службе («объету2») стартовать от имени текущего пользователся… но результат оказался тем же самым. Создавалось два процесса «объекта1», но уже от имени одного и того же пользователя. Вообще насколько это допустимо, чтобы служба (более низкий уровень) являлась инициатором соединения с обычным COM приложением (пользовательский уровень)? Это к тому, что скажем с пользовательского уровня можно обратиться к драйверу, но из драйвера в пользовательское – никогда. Или со службами совсем другая идеология. Объясните, плиз, или дайте ссылки, где можно об этом подробно почитать. Буду признателен за любые идеи!

P.S. Реализация «объекта1» тоже в виде службы Win32 НЕ допустима.

← →
Ломброзо © (2006-11-03 00:53) [1]

Не получится. Это фича бай дизайн подсистемы безопасности DCOM. Если сервис работает от имени SYSTEM и включена имперсонификация, то COM Service Control Manager запускает серверный процесс от имени пользователя, пытающегося осуществить удаленную активацию. Если, к примеру, два вызова имеют одинаковый identity - будет запущен единственный процесс, если разные - запустит два. Выход только один - запускать сервис с явно заданной учетной записью, отличной от системных.

← →
Ломброзо © (2006-11-03 01:02) [2]

Сорри, невнимательно читал, и мне показалось, что EXE-COM-сервер вы зашили в службу Win, а на самом деле COM-сервер у вас - это обычное приложение, в смысле - не служба. Но сути дела это не меняет.

Попробуйте создать тестовую учетную запись, покрутите настройки вашего EXE-COM-сервера в dcomcnfg и задайте ему опцию стартовать не от имени interactive user, launching user или системных учетных записей, а от имени тестовой учетной записи.

← →
Note (2006-11-03 09:55) [3]

>> Попробуйте создать тестовую учетную запись, покрутите настройки вашего EXE-COM-сервера в dcomcnfg

Спасибо, помогло именно это: указал у "объекта1" запускать от "текущего пользователя", как всё заработало — и служба ("объект2") и "объект3" стали использовать один и тот же "объект1".

>> Если сервис работает от имени SYSTEM и включена имперсонификация, то COM Service Control Manager запускает серверный процесс от имени пользователя, пытающегося осуществить удаленную активацию.

В моём проекте также есть служба Win32, где зашит EXE-COM-сервер и в которой указано запускаться от имени SYSTEM. Что такое имперсонификация и включена ли она - я не знаю :). Обычные приложения (не службы), запущенные под учётной записью текщего пользователя прекрасно подключаются к этой службе и работают с ней (причём она стартует именно от имени SYSTEM, а не от имени "пользователя, пытающегося осуществить удаленную активацию"). Правда всё это происходит локально (на одном и том же компьютере). То о чём Вы пишете - это правило только для подключения с удалённого компьютера? Где об этом можно подробно почитать?

← →
Ломброзо © (2006-11-03 10:35) [4]

>это правило только для подключения с удалённого компьютера
нет, это общие правила для межпроцессного и межхостового (велик и богат русский язык) взаимодействия

>Где об этом можно подробно почитать

в MSDN

← →
Note (2006-11-03 10:48) [5]

> нет, это общие правила для межпроцессного и межхостового (велик и богат русский язык) взаимодействия

тогда я Вас не понимаю... тест показывает, что серверный процесс EXE-COM-сервера (другими словами служба) запускается ВСЕГДА именно от имени SYSTEM, а не от, как Вы пишете, от имени "пользователя, пытающегося осуществить удаленную активацию". Будь у меня 10 различным приложений, запущенных под 10-ю различными учётными записями пользователей - они все соединяются с ОДНИМ и тем же серверным процессом (службой), которая запускается от имени SYSTEM.

← →
Note (2006-11-03 11:43) [6]

Вот, что нашёл в MSDN в дополнение своих слов:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q169321

Multiple-use Classes
Service-based COM servers. A COM class/AppID that is packaged in a Win32 service is by practical necessity a multiple-use server since services can be launched only once. In this case, at the first activation request a new process is launched in its own window station....All subsequent activation requests, whether local or remote, are handled by the service"s class object.

Single-Use Classes
Service-based COM servers. Single-use classes should never be implemented as Windows NT services. It makes no sense, because it is not possible to run multiple instances of an Windows NT service process.

Другими словами два процесса службы Win32 (даже когда она является EXE COM сервером) существовать ни как не могут, не зависимо от identity.

http://msdn.microsoft.com/msdnmag/issues/1100/wicked/

COM взаимодействие службы Win32 и пользовательского приложения Найти похожие ветки