CreateFileMapping und Admin-Mode

[UliBru]

Ich habe eine Anwendung bei der zwei Programme per IPC kommunizieren und zwar erfolgreich.
Das läuft unter Verwendung von CreateFileMapping. Soweit ok.

Nun hat ein Anwender aus irgendeinem Grund das eine Programm im Admin-Mode laufen lassen. Dann klappt die Kommunikation nicht mehr.
Wenn wiederum beide Programme im Admin-Mode laufen, dann klappt es wieder.

Was muss man machen, damit es immer läuft? Es sieht ja so aus, als ob bei unterschiedlichen User-Modi unterschiedliche Speicherbereiche beim CreateFileMapping zugewiesen werden.

Grüsse
Uli

[Der schöne Günther]

Hast du ein bisschen Code? Spontan hätte ich anhand des Namens getippt, dass das etwas damit zu tun haben könnte:

Zitat:

The name can have a "Global\" or "Local\" prefix to explicitly create the object in the global or session namespace. The remainder of the name can contain any character except the backslash character (\). Creating a file mapping object in the global namespace from a session other than session zero requires the SeCreateGlobalPrivilege privilege. For more information, see Kernel Object Namespaces.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Zitat:

SE_CREATE_GLOBAL_NAME

Required to create named file mapping objects in the global namespace during Terminal Services sessions. This privilege is enabled by default for administrators, services, and the local system account.
User Right: Create global objects.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

[UliBru]

Ich verwende bisher u.a. den Aufruf

  hmmfApplicationName := CreateFileMapping(INVALID_HANDLE_VALUE, nil, PAGE_READWRITE, 0, SizeOf(TmmfApplicationName), PChar('AppNameXYZ'));

Vermutlich liegt das Problem daran, dass der zweite Parameter nil ist.
Dass also anstelle von nil ein passender Pointer auf SecurityAttributes übergeben werden muss, so dass jedes andere Programm auf das memory mapped file bekommt, auch wenn eben das CreateFileMapping im Admin-Mode ausgeführt wird.

Soweit ich mittlerweile herausgefunden habe scheint wohl die Lösung darin zu liegen

Zitat:

Ah the infamous NULL security issue. This applies to all security attributes in Win32. The problem is that a NULL security attribute means you want to use the default security of the process/thread. This means it is specific to a user. If you want anybody to have access to the object in question then you need to instead use a NULL descriptor (which is different). A NULL descriptor is a DACL that is set to NULL. This means anybody has access.

Jetzt müsste ich bloss wissen, wie man das in Delphi korrekt anstellt. NULL und nil scheinen dabei auch nicht dasselbe zu sein.

Grüsse
Uli

[Der schöne Günther]

Ich kenne mich mit diesem DACL-Kram nicht aus, aber der Unterschied ist einen leeren Zeiger anzugeben (nil in Delphi, NULL / nullptr in C++) und ein Objekt ohne wirklichen Inhalt anzugeben

https://blogs.technet.microsoft.com/...d-empty-dacls/

[Zacherl]

So sollte es funktionieren. Warum ich damals bInheritHandle auf true gesetzt habe, kann ich dir allerdings grade nicht mehr sagen:

Delphi-Quellcode:

var
  FSA: SECURITY_ATTRIBUTES;
  FSD: SECURITY_DESCRIPTOR;
begin
  InitializeSecurityDescriptor(@FSD, SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(@FSD, true, nil, false);
  FSA.lpSecurityDescriptor := @FSD;
  FSA.nLength := SizeOf(SECURITY_ATTRIBUTES);
  FSA.bInheritHandle := true;
  Event := CreateEvent(@FSA, true, false, 'Global\MyEvent');

Der Code wurde aus einem Service heraus aufgerufen, weshalb es sein kann, dass das "Global" bei dir nicht funktioniert. In diesem Falle einfach weglassen.

[himitsu]

Es kommt drauf an, ob man später das Handle erben lassen will, oder ob OpenFileMapping ein neues Handle auf das selbe Mapping erstellt.

Aber vorallem wenn man bInheritHandle=True beim OpenFileMapping angibt, dann wäre es definitiv nötig.

Zitat:

Der Code wurde aus einem Service heraus aufgerufen, weshalb es sein kann, dass das "Global" bei dir nicht funktioniert. In diesem Falle einfach weglassen.

Es muß global sein, denn local laufen beide Programme in verschiedenen Sessions, wenn nur Eines als Admin läuft, oder seh ich das falsch?

[UliBru]

Danke.

Delphi-Quellcode:

var
  aSA: TSecurityAttributes;
  aSD: TSecurityDescriptor;
begin
  InitializeSecurityDescriptor(@aSD, SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(@aSD, True, nil, False);
  aSA.nLength := SizeOf(TSecurityAttributes);
  aSA.bInheritHandle := true;
  aSa.lpSecurityDescriptor := @aSD;
  ... 
  hmmfApplicationName := CreateFileMapping(INVALID_HANDLE_VALUE, @aSA, PAGE_READWRITE, 0, SizeOf(TmmfApplicationName), PChar('AppNameXYZ'));
  ...

klappt soweit. Nun gibt es noch ein weiteres Problem, ich mach dazu aber ein neues Thema auf.

Grüsse
Uli

PS: wenn ich da noch 'Global\\' dazunehme gibt es eine Exception.

[Zacherl]

Zitat von himitsu:

Es kommt drauf an, ob man später das Handle erben lassen will, oder ob OpenFileMapping ein neues Handle auf das selbe Mapping erstellt.

Ich glaube das hast du falsch verstanden. Die Handle Inheritance bezieht sich auf Child-Prozesse. Inheritable Handles bleiben dann auch dort gültig. Im Grunde genommen wird hier DuplicateHandle für jedes entsprechende Handle aufgerufen um es im Child Prozess gültig zu machen.

Zitat von himitsu:

Zitat:

Der Code wurde aus einem Service heraus aufgerufen, weshalb es sein kann, dass das "Global" bei dir nicht funktioniert. In diesem Falle einfach weglassen.

Es muß global sein, denn local laufen beide Programme in verschiedenen Sessions, wenn nur Eines als Admin läuft, oder seh ich das falsch?

Ne, die Session bezieht sich wirklich auf die physikalische Sitzung bzw. eine Remote Desktop Session und bleibt sogar dann gleich, wenn man mit RunAs ein Programm unter dem Benutzerkontext eines komplett anderen Benutzers startet. "Global" ist eigentlich nur dann erforderlich, wenn man z.b. mit einem Service kommunizieren will, da diese ja seit Vista unter der abgekapselten Session 0 laufen.