Vista und die Dateierweiterung (UAC "On-Demand")

[himitsu]

ich hatte mal vor Langem was mit CreateProcessAsUser gemacht und da vorher eine Userliste ausgelesen, diese in einem ialog angezeigt und dann selber gefragt ... k.A. ob/wie das anders geht, aber zumindestens passte es so in den Style des Programmes rein

[add] Es könnte sein, daß ein Dialog aufpoppt, wenn man kein Passowrt bzw. Benutzernamen angibt?

[MCXSC]

Zitat von jaenicke:

Einen laufenden Prozess kann man aus Sicherheitsgründen nicht nachträglich mit Adminrechten ausstatten. Die bekommt man beim Start oder nicht.

Doch, genau das ist (zumindest mit Vista und W7) möglich. Siehe Screenshot. Das Programm (KeePass btw) wird ganz normal (also ohne UAC oder Adminrechte) gestartet. Für jene Verknüpfung braucht man (da Registryeintrag) eben Adminrechte; nach dem Drücken des Buttons fragt UAC eben nach ob das erlaubt werden soll (und es ist und bleibt die KeePass.exe - also wird keine zweite EXE aufgerufen).

[Elvis]

Zitat von MCXSC:

Zitat von jaenicke:

Einen laufenden Prozess kann man aus Sicherheitsgründen nicht nachträglich mit Adminrechten ausstatten. Die bekommt man beim Start oder nicht.

Doch, genau das ist (zumindest mit Vista und W7) möglich. Siehe Screenshot. Das Programm (KeePass btw) wird ganz normal (also ohne UAC oder Adminrechte) gestartet. Für jene Verknüpfung braucht man (da Registryeintrag) eben Adminrechte; nach dem Drücken des Buttons fragt UAC eben nach ob das erlaubt werden soll (und es ist und bleibt die KeePass.exe - also wird keine zweite EXE aufgerufen).

Dann wird eben KeePass.exe ein zweites mal gestartet. Windows hat leider keine Funktionalität um Threads oder bestimmte APIs getrennt zu priviligieren. Es gibt in Windows also nur die große Keule: Admin ja oder nein.

Oh und btw, der User-level Knoten, der HK_CR abbildet ist HK_CU/Software/CLasses.
Damit kannst du sowohl COM-Registraturen erledigen, also auch File-extensions verknüpfen.[1]

Wobei man mit Fileextensions eigentlich nur sagen sollte: "Jupp, mein Tool kann .xyz öffnen", aber nicht als Default einzutragen.
Einfach so umbiegen hat so einen penetranten Beigeschmack, IMO.

[1] Wenn es en .Net COM Server ist, kann regasm das schon von sich aus.
Für native COM Server musst du regcap.exe aus dem WindowsSDK nehmen. Das gibt dir eine .reg Datei anstelle einer Registrierung, und die kannst du einfach von HK_CR auf HK_CU/Software/Classes ändern.
Für UAC brauchst du einen Out-Of-Process COM Server.

[jaenicke]

Zitat von MCXSC:

und es ist und bleibt die KeePass.exe - also wird keine zweite EXE aufgerufen

Wurde das Programm installiert? Dann kann auch eine DLL registriert worden sein und diese die Registrierung übernommen haben, davon siehst du ja nichts. Das hat Elvis ja in der letzten Zeile auch erwähnt.

Oder es hat sich eben wie gesagt selbst neu gestartet. So mache ich es ggf. auch, damit ich auf dem Rechner nix vorher installieren muss.

[Dezipaitor]

Zitat von MCXSC:

Zitat von mirage228:

Vielleicht hilft Dir ja dieser Artikel darüber:
http://blog.delphi-jedi.net/2008/03/...ta-with-jwscl/

Nachdem ich mir das ganze nochmals angesehen habe: Nein, leider nicht wirklich. Hier müsste man ja - sofern ich den Ansatz richtig verstehe - nochmals mittels Adminrechte eine COM registrieren... Dann kann ich direkt das ganze Programm so mit Adminrechten starten lassen.

Nur gibt es manche "One-EXE-Programme", die anfangs keine Abfrage haben (und dementsprechend auch keine COM-Datei registrieren) und trotzdem nur für bestimmte Funktionen explizit Adminrechte anfordern. Bringt Vista da wirklich keine eigene Abfrage mit?

So, wie ich es sehe, hast du den Artikel nicht verstanden. Er beschreibt nämlich zwei mögliche Ansätze, um Elevation zu nutzen. Der erste Ansatz ist der ShellExecute Ansatz mit dem runas-Verb, welches auf die eigene Exe-Datei angewendet wird (du hast sie "One-EXE-Programme" genannt). Der zweite Ansatz nutzt dann erst COM, um mit seiner Hilfe spezielle Methoden mit Adminrechten auszuführen.

Der erste Ansatz hat den Vorteil, dass es Addhoc geht, also keine Installation notwendig ist. Der Nachteil besteht jedoch darin, dass die Kommunikation auwändig ist. Wurde alle richtig ausgeführt? Was ist mit den Resultaten? Da wirst du nicht um eine Interprozesskommunikation herumkommen, wenn du dich nicht auf den Prozessrückgabewert beschränken willst.
Der zweite Ansatz, wie du schon weißt, hat den Nachteil, dass man ein COM-Objekt bei Windows registrieren muss. Die Windowsinstaller (MSI) besitzen jedoch schon einen Dienst, der es ermöglicht, dass erst bei einer Notwendigkeit, die UAC aufpoppt (z.b. vor dem Dateikopieren). Der Vorteil im zweiten Ansatz besteht darin, dass man eine ganz normale Methode aufruft und alle Daten, die als Parameter übergeben oder von der Methode zurückgeliefert werden, von COM (mit Einschränkungen) verwaltet werden.

[jaenicke]

Zitat von Dezipaitor:

Da wirst du nicht um eine Interprozesskommunikation herumkommen, wenn du dich nicht auf den Prozessrückgabewert beschränken willst.

Wobei das ja z.B. mit MMFs, Messages, ... relativ einfach ist Daten hin- und herzuschieben.

Die Vorgehensweise mit COM finde ich da eher schwieriger zu implementieren, auch wenn die Verwendung danach einfacher ist.

[Dezipaitor]

Nicht ganz so einfach, wie man denkt. Da WindowsNachrichten nicht so einfach funktionieren, wenn man mit Adminprozessen reden will. Und den Rest, naja, da kommen immernoch die Rechtegeschichten zum tragen, d.h. DACL.

[jaenicke]

Ich muss zugeben, dass ich mich da nicht so viel mit beschäftigt habe, aber bisher klappt das wie es soll mit der Kommunikation in beide Richtungen. *klopft auf Holz*