Intrasession Communication with .NET Remoting

Question

У меня есть приложение, которое должно быть вызвано вторым приложением. Эти приложения должны находить друг друга без конфигурации (желательно, не касаясь реестра) и работать в среде служб терминалов должным образом. Я слышал, что удаленное использование .net с использованием именованных каналов может быть способом выполнить это, но я не понимаю, как ограничить доступ к каналу только в течение сеанса, который его создал. Спасибо

Обновление: У меня все хорошо с WCF, вопрос не является специфичным для удаленного доступа, но как установить именованный канал для локального сеанса.

Answer 1

Если ваше приложение работает в Windows Vista или Windows 7, и вы используете WCF NetNamedPipeBinding, вы автоматически получите услугу, доступную только с одного и того же сеанса. ПРЕДОСТАВЛЯЕТ, что процесс, который реализует конец службы у трубы нет привилегии SeCreateGlobalPrivilege. На практике это обычно означает, что сервер может быть любой программой, запущенной в интерактивном сеансе, при условии, что она не запущена с помощью «Запуск от имени администратора».

Причина, по которой это так относится к именованному объекту общей памяти, который WCF создает для публикации фактического имени канала (GUID) для потенциальных клиентов. I explain this mechanism on my blog. Если сервисный процесс имеет SeCreateGlobalPrivilege, этот объект публикации создается в пространстве имен Global kernel, видимом для всех сеансов; если он не имеет этой привилегии, объект создается в пространстве имен локального ядра, видимом только в пределах одного сеанса. Обратите внимание, что это не обеспечивает абсолютной безопасности: сам именованный канал можно было бы получить в теоретическом виде из другого сеанса (используя собственные вызовы API, а не стек WCF), если бы идентификатор GUID канала каким-то образом был раскрыт другим способом.

Если вам нужна поддержка более ранней ОС или если вы хотите абсолютную безопасность самого канала, вам нужно будет реализовать это ограничение явно, изменив DACL на трубе после того, как стек канала WCF создал его. Это требует некоторого вмешательства со стандартной привязкой, и я показываю how this can be done here. Вам также необходимо написать код P/Invoke, который не является особенно простым, чтобы обнаружить правильный SID сеанса входа в систему, для которого необходимо создать ACE в DACL. В .NET 4 сам стек службы WCF обнаруживает и использует идентификатор сеанса входа в систему, чтобы ограничить разрешение на создание новых экземпляров канала, чтобы вы могли использовать Reflector, чтобы посмотреть, как он это делает - см.: System.ServiceModel.Channels.SecurityDescriptorHelper.GetProcessLogonSid().

Answer 2

Я бы рекомендовал использовать для этого Windows Communication Foundation.

Вы бы иметь возможность настройки, без использования реестра, все различные варианты связи, в том числе с использованием именованных каналов, розетки и т.д.

Answer 3

Я искал в этой конкретной проблемы. Лучшее решение, которое я нашел до сих пор (но еще не пробовал), это создать уникальное имя именованного канала, используя session id.