Laden...

IPC Remoting Zugriff verweigert

Erstellt von der Marcel vor 17 Jahren Letzter Beitrag vor 17 Jahren 7.207 Views
der Marcel Themenstarter:in
564 Beiträge seit 2006
vor 17 Jahren
IPC Remoting Zugriff verweigert

Hallo!

Ich schreibe zur Zeit an einem Windows-Dienst und habe mir gedacht, per Remoting kommende Exceptions in einer Konsolenanwendung ausgeben zu lassen. Die Kommunikation läuft über IPC. Es wird dabei remote eine Methode der Konsolenanwendung aufgerufen, welcher das Exception-Objekt übergeben wird. Der Windows-Dienst ist dabei der Client und die Konsolenanwendung der Server.
Wenn der Client-Code in einer normalen Anwendung steht, funktioniert er super. Das selbe bringt aber als Windows-Dienst eine RemotingException mit dem Hinweis zutage, dass der Zugriff aud den IPC-Port verweigert wurde.
Es dürfte an Sicherheitseinstellungen liegen, aber ich finde keinen Ansatz an dieser Stelle weiterzukommen. Kann sich das jemand von euch erklären?

Zur Ergänzung den betreffenden Code:

ChannelServices.RegisterChannel(new IpcChannel(), true);
RemotingConfiguration.RegisterWellKnownClientType(typeof(RemoteObject), "ipc://exConsole/exRemote");//Registrierung als Remote-Typ
RemoteObject remote = new RemoteObject();
remote.ShowException(new Exception("Test"));// an dieser Stelle kommt die Exception, wenn dies ein Windows dienst ist, sonst nicht

Bin euch für jede Hilfe dankbar!

Der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

S
143 Beiträge seit 2006
vor 17 Jahren

Du musst bei NamedPipes eine Hashtable mit SecuritySettings als Parameter mit auf den weg geben. Neues Sicherheitsfeature. Ungefähr so:


Hashtable h = new Hashtable();
h.Add("impersonationLevel", "None");
h.Add("authorizedGroup", "Jeder");
BinaryServerFormatterSinkProvider provider = new BinaryServerFormatterSinkProvider();
IChannel ch = new IpcServerChannel(h, provider);

Die wichtigeste Zeile ist der Eintrag authorizedGroup in der Hashtable.
Beachte aber, das mein Beispiel nicht auf einem OS mit anderer Sprache laufen wird!

S
143 Beiträge seit 2006
vor 17 Jahren

Hier findest Du ein Beispiel:
http://www.netbrick.net/blog/PermaLink,guid,0609dbda-a360-404a-804d-895b941384f2.aspx

Falls Du Dein Programm auch unter andren OS brauchst und mit "Jeder" nicht mehr hinkommst, kann ich Dir auch helfen.

der Marcel Themenstarter:in
564 Beiträge seit 2006
vor 17 Jahren

Hallo Sascha M!

Danke für deine Antwort! Wenn ich wieder an der Entwicklungsumgebung bin, werde ich mir das anschauen. Klingt nach einer guten Lösung! Habe bisher die Kommunikationsrichtung umgedreht und versuche es mit Events zu lösen. Der Test steht aber noch aus. Gut anzunehmen, dass das selbe Problem auftritt 🙂

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

der Marcel Themenstarter:in
564 Beiträge seit 2006
vor 17 Jahren

Hallo Sacha M!

Mit dem, was du geschrieben hast, klappt es. Wie sieht denn dein Lösungsansatz aus um es auch auf andersprachigen OS zum Laufen zu bekommen? Spontan würde ich sagen, dass ich mir die Gruppennamen aus der Registry oder WMI hole.
Der IPC-Zugriff wird zwar jetzt nicht mehr verweigert, aber ich bin jetzt auf client seite (kein dienst) auf ein weiteres Problem gestoßen. Und zwar möchte ich eine Methode der Konsolenandwenung beim Event des Remote-Objektes registrieren. Bei eben dieser Registrierung kommt eine SecurityException

SecurityException
Der Typ System.DelegateSerializationHolder und die davon abgeleiteten Typen (z.B. System.DelegateSerializationHolder) dürfen in dieser Sicherheitsebene nicht deserialisiert werden.

Hast jemand eine Idee, wie ich an diese Sicherheitsebene komme?

der Marcel

EDIT: Habe jetzt noch folgende Eigenschaften vom provider gesetzt:

provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;

Nun ist die SecurityException weg aber ebenfalls beim Registrieren kommt nun eine TargetInvocationException

TargetInvocationException
Ein Aufrufziel hat einen Ausnahmefehler verursacht.

Hat jemand eine Idee?

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

der Marcel Themenstarter:in
564 Beiträge seit 2006
vor 17 Jahren

Hi!

Bin heute auf meiner Suche nach dem Problem fündig geworden. Habe dem Dienst einen Verweis auf die Client-Assembly gegeben, was dieses behebt. Es wird zwar nun der ganze Code ohne Exceptions ausgeführt, aber die Events, welche im Dienst gefeuert werden kommen remote nicht an...Es könnte ja mal was funktionieren... 🙁

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

S
143 Beiträge seit 2006
vor 17 Jahren

Hallo!

Schön das es geklappt hat. Das mit den Sprachen poste ich am Montag, wenn ich wieder an der Arbeit bin. Aus dem Kopf weiss ich das nicht mehr.

der Marcel Themenstarter:in
564 Beiträge seit 2006
vor 17 Jahren

Hi Sascha M!

Jep, das hat prinzipiell geklappt. 🙂 Nur mit den Events quäle ich mich noch. Mein neuer Lösungsansatz ist, interfaces für Client und Server bereitzustellen, so dass sich ein Client am Server anmelden kann und der Server im Client Events feuert. Das sollte theoretisch eigentlich klappen.
Das ist nett von dir nochmal wegen der Mehrsprachigkeit nachzuschauen! Bis Montag!

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

S
143 Beiträge seit 2006
vor 17 Jahren

Mehrsprachigkeit:


SecurityIdentifier Sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
NTAccount Account = (NTAccount)Sid.Translate(typeof(NTAccount));

Mit Account.Value bekommst Du dann die Gruppe in der jeweiligen Sprache (Jeder, Everyone, etc.)

Viel Spass
Sascha

der Marcel Themenstarter:in
564 Beiträge seit 2006
vor 17 Jahren

Hi Sascha M.!

Funktioniert ja prima 🙂 Danke!

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

S
143 Beiträge seit 2006
vor 17 Jahren

Sehr gut. Dann bin ich auch zufrieden.