безопасность и DCOM

[dumb]

имеется MMC snap-in, при загрузке он создает COM-объект на удаленной машине и получает его IPersistStorage. Открывает локальный файл и получает его IStorage. вызывает IPersistStorage::Load с этим IStorage. при настройках по умолчанию получает "нет доступа". если вызвать CoInitializeSecurity(NULL,-1,NULL...), то все работает, но это проверено на тестовой программе, а внутри MMC эта функция уже вызвана. полагаю, следует ковыряться в прокси IStorage который я передаю в IPersistStorage::Load. есть ли более простое и логичное решение? (логичное в смысле, что мне не нужна безопасность на интерфейсах, которые я передаю удаленному объекту).

[NetRaider]

А на файл разрешения стоят правильные?
Если удаленный объект создается и другие методы вызываются без ошибок, тогда можно перед вызовом Load можно попробовать сделать так:
CoSetProxyBlanket(pIPersistStorage,
        RPC_C_AUTHN_NONE,
        RPC_C_AUTHZ_NONE,
        NULL,
        RPC_C_AUTHN_LEVEL_NONE,
        RPC_C_IMP_LEVEL_IDENTIFY,
        NULL,
        EOAC_NONE);

[NetRaider]

или на сервере клиента имперсоонировать

[Гром]

А пояснить мне как ... полному 0 в этом можно??? Интересно...

[NetRaider]

А пояснить мне как ... полному 0 в этом можно??? Интересно...

А что конкретно интересует ?

[dumb]

А на файл разрешения стоят правильные?
Если удаленный объект создается и другие методы вызываются без ошибок, тогда можно перед вызовом Load можно попробовать сделать так:
CoSetProxyBlanket(pIPersistStorage,
        RPC_C_AUTHN_NONE,
        RPC_C_AUTHZ_NONE,
        NULL,
        RPC_C_AUTHN_LEVEL_NONE,
        RPC_C_IMP_LEVEL_IDENTIFY,
        NULL,
        EOAC_NONE);

можно, конечно... не знаю -- попробую... но вопрос более общий: а что если удаленный объект сам захочет обратиться к интерфейсу, который я ему передал? (: первоначальный вопрос можно переформулировать так: есть ли возможность расставить разрешения на интерфейсы со стороны сервера, причем детально, на каждый -- свои, не в стиле CoInitializeSecurity? есть, конечно, и замечательно простое решение (: -- в настройках DCOM "разрешения доступа по умолчанию" установить доступ для всех... но это уж слишком круто, IMHO

[Гром]

NetRaider, все... с самого начала.

[NetRaider]

есть ли возможность расставить разрешения на интерфейсы со стороны сервера, причем детально, на каждый -- свои

Это зависит от платформы на которой сервер крутится.
1)В W2k просто, там в COM+ реализована ролевая защита, похожая на группы в NT. Можно отдельные права выставлять как на интерфейс, так и на методы, причем это возможно делать програмно, либо декларативно - через средства администрирования.

2)NT4
Здесь только руками
В реализации QueryInterface сервера вызвать
1. CoImpersonateClient
2. OpenThreadToken
3. Вытащить из токена SID пользователя и проверить(используя AccessCheck, либо свой метод), можно ли ему возвращать запрошенный интерфейс.Если нельзя тогда return E_ACCESSDENIED.

Вместо шагов 2 и 3 можно соорудить маленькую хитрость -
Создать обьект ядра на который навешиваются права доступа. Хорошо подходит ветка реестра - необходимо содать несколько веток и назначить некоторым пользователям права на них. В коде QueryInterface после имперсоонации попытаться открыть эти ветки.

Если необходима настройка прав на методы интерфейса - тогда придется для каждого(!) метода применять вышеописанный подход, что IMHO гемор полный.

а что если удаленный объект сам захочет обратиться к интерфейсу, который я ему передал?

А что ему мешает ? Или это про ConnectionPoint'ы ?

[dumb]

это ИМЕННО про ConnectionPoint'ы   кроме того, с общим рабочим решением все понятно... вопрос был именно о наиболее простой реализации