Почему делает именованный канал сервисные клиенты службы Windows отклонения WCF?

В Windows 7 и.NET 4 я получаю некоторые очень странные эффекты от транспорта именованного канала WCF, когда мой клиент WCF является службой Windows.

Мой сервис WCF размещается в приложении непривилегированного режима и подвергается по привязке именованного канала.

Мой клиент WCF является службой Windows, работая как Сетевая служба (я получаю тот же результат, если это работает как Локальная Система).

Если мое приложение непривилегированного режима (т.е. сервис WCF) работает как администратор домена затем, это хорошо работает, но если приложение непривилегированного режима является обычным пользователем (или локальный администратор) затем, соединение отклоняется с CommunicationObjectFaultedException.

Я видел некоторые вопросы, на здесь касаясь включаемого контроля учётных записей, но я не видел фактического решения нигде, которое просто заставляет транспорт именованного канала работать правильно. Это - просто неизбежная ошибка платформы?

6
задан Mat 6 November 2013 в 05:53
поделиться

1 ответ

Из записи блога Кристиана Вейера Работа с "проблемами" привилегий ОС в сценариях именованных труб WCF:

Если мой серверный процесс WCF, использующий конечную точку на основе именованных труб, не имеет привилегий для создания глобального объекта ядра, он молча терпит неудачу и создает локальный объект, который не будет виден процессам вне его сессии.

Таким образом, ни один основанный на именованной трубе механизм связи (WCF или иначе), открытый процессом без привилегии создать глобальный объект ядра, никогда не будет в состоянии получить сообщения от вне его собственной сессии.

Кажется, что это пример закона непреднамеренных последствий, где зажимание безопасности фактически приводит к тому, что люди открывают больше лазеек в безопасности, будучи вынужденными использовать видимые в сети транспорты вместо механизма IPC локальной машины. MS должна действительно обеспечить надлежащий IPC канал для WCF, потому что текущий именованный транспорт трубы не режет его.

Проблема в том, что это не особенно необычный сценарий, для службы .NET, чтобы хотеть говорить с приложением лотка .NET, чтобы обеспечить пользовательские уведомления. Механизм опроса от приложения tray к сервису будет работать... но опрос медленный и ресурсоемкий, и я бы хотел избежать его.

Кто-нибудь знает лучший пользовательский IPC-транспорт?

Tim

4
ответ дан 17 December 2019 в 06:59
поделиться
Другие вопросы по тегам:

Похожие вопросы: