[Vista] Programm explizit ohne Administratorrechte starten

**H4ndy**

Hallo,

ich hab hier eine kleine Verständnisfrage.
Und zwar habe ich unseren Online Updater überarbeitet, so dass er sich ins Vista-UAC-Konzept einpasst.

Das beinhaltet, dass es jetzt zwei EXEn gibt:
Eine führt die reine Überprüfung nach Updates aus und hat ein Vista-Manifest mit "asInvoker" als Rechteanforderung.
Gibt es Updates, dann erhält der "Download & Install"-Button ein Vista-UAC-Schild per API und auf Klick wird die zweite
EXE mit passenden Parametern gestartet. Diese hat "requireAdministrator" im Manifest, da im Programmeverzeichnis hantiert wird. Der Aufruf erfolgt per ShellExecute, damit die UAC-Abfrage kommt statt einer Fehlermeldung, was auch wunderbar funktioniert.

Jetzt gibt es ein spezielles Problem. Und zwar muss der "Checker" sich selbst neustarten können. Das habe ich realisiert, in dem ich den "Downloader" mit einem speziellen Parameter starte, der dafür sorgt, dass der Downloader im OnCreate einfach die Checker.exe starte und sich dann selbst beendet. Soweit, so gut. Das Problem ist jetzt, dass der durch den Downloader gestartete Checker anscheinend mit den Adminrechten des Downloaders läuft und somit nicht mehr in die richtigen Registry-Zweige kommt (um die Registry komm ich momentan nicht drum herum).

Meine Frage ist jetzt, wie ich den Checker starten kann, als würde er vom User oder von einer "asInvoker"-EXE gestartet werden.
ShellExecute funktioniert nicht, CreateProcess hat das gleiche Problem

Impersonation fällt flach, da ich den aktuellen User ja net nach seinem Passwort fragen kann.

**Luckie**

Zitat von H4ndy:

Impersonation fällt flach, da ich den aktuellen User ja net nach seinem Passwort fragen kann.

Warum kannst du den aktuellen Benutzer nicht nach seinem Passowrt fragen? Oder meinst du das Passwort des Administrators? Aber das ändert nichts an meiner Frage, da der Administrator in der Regel die Updates macht, eben wegen der Berechtigungen.

Anregung für andere Mitglieder: Könnte mal jemand, der sich mit Vista auskennt eine prinzipielle Vorgehensweise erstellen? Wäre eventuell ein Thema für ein Tutorial. Wenn dann noch eine schöne Demo dazu erstellt wird, wäre das sicherlich ein wertvoller Beitrag für die Community. Denn anscheinend gibt es immer wieder Probleme bei diesem Thema, owohl es schon oft erläutert wurde. Aber eine Zusammenfassung und mal eine Klärung des Problems wäre schön.

**Elvis**

Nur mal als ein Ansatzpunkt (oder 3)

Du könntest dem "Checker" per Named Pipe oder einem anderen IPC-Weg die Nachricht zukommen lassen, er solle sich doch gefälligst neu starten.
Da er noch im originalen asInvoker-Kontext läuft, könnte er sich einfach neu starten und anschließend beenden.
Eine andere Möglichkeit, die ich selbst fast ausnahmlos bevorzuge, ist es zu verhindern, dass sie die App neu starten muss.
Ganz einfach indem die App selbst nur eine Art Bootstrap für DLLs ist und einfach diese DLLs neu laden könnte um ein komplett neues Verhalten zu bekommen. Je weniger Code in der Exe liegt umso geringer ist die Chance, dass du sie überhaupt aktualisieren müsstest.
Der Knackpunkt: Warum braucht der Update-Mechanismus überhaupt erhöhte Privilegien?
Ich versuche meine Clients möglichst so zu gestalten, dass sie keine globalen Auswirkungen auf das System haben. (Bei Services ist das natürlich anders, aber auch die kann man soweit wie möglich isolieren.)
IOW: Alle Settings sind strikt per-User, und auch das Setup ist per-User.
Dadurch muss ein potenzieller User nicht erst mit der IT darüber verhandeln ob oder wann er die App kriegt. Schließlich hat sie ja nur Einfluss auf das, was der User sowieso schon darf.

**Luckie**

Zitat von Elvis:

Nur mal als ein Ansatzpunkt (oder 3)

Der Knackpunkt: Warum braucht der Update-Mechanismus überhaupt erhöhte Privilegien?

Weil das zu aktualisierende Programm in einem Ordner installiert wurde, in dem nur der Administrator Schreibrechte hat, wie es sich auch gehört.

**H4ndy**

Zitat von Luckie:

Warum kannst du den aktuellen Benutzer nicht nach seinem Passowrt fragen? Oder meinst du das Passwort des Administrators? Aber das ändert nichts an meiner Frage, da der Administrator in der Regel die Updates macht, eben wegen der Berechtigungen.

Ich sehe das aus Usersicht. Ich würde einem offensichtlichen Online-Programm nicht mein Windowspasswort in einem eigenen Dialog geben, von daher halte ich das für unpraktikabel. Beim Admin mag das gehen, da er sich i.d.R. mit einem Programm was er nutzt auch auseinander setzt und da dann auch mehr oder weniger Vertrauen drin hat.

Zitat von Elvis:

Da er noch im originalen asInvoker-Kontext läuft, könnte er sich einfach neu starten und anschließend beenden.

Auf die Idee bin ich garnicht gekommen, dass das ja auch geht. Werde ich mal testen, ob das mit dem aktuell eingebautem Mutex klappt.

Zitat von Elvis:

Eine andere Möglichkeit, die ich selbst fast ausnahmlos bevorzuge, ist es zu verhindern, dass sie die App neu starten muss.

Diese Möglichkeit habe ich auch bedacht und habe es vorhin auch geschafft diese umzusetzen (war etwas Mühsam, funktioniert aber). Klappt aber leider nicht immer so...

Zitat von Elvis:

Ganz einfach indem die App selbst nur eine Art Bootstrap für DLLs ist und einfach diese DLLs neu laden könnte um ein komplett neues Verhalten zu bekommen. Je weniger Code in der Exe liegt umso geringer ist die Chance, dass du sie überhaupt aktualisieren müsstest.

Interessanter Ansatz, werde ich für zukünftige Projekte mal in betracht ziehen.

Zitat von Elvis:

Der Knackpunkt: Warum braucht der Update-Mechanismus überhaupt erhöhte Privilegien?

Luckie hat alles gesagt

Jedenfalls ist das Problem auf meiner Seite gelöst, da ich es nun geschafft habe den Neustart zu vermeiden. Ändert aber nix an der Fragestellung ob es möglich ist, dass ein Admin-Programm ein anderes im User-Kontext "einfach so" starten kann.

Danke für die vielen Anregungen!

**Reinhard Kern**

Zitat von H4ndy:

... Ändert aber nix an der Fragestellung ob es möglich ist, dass ein Admin-Programm ein anderes im User-Kontext "einfach so" starten kann.

Hallo,

das darf nach der Sicherheitsphilosophie garnicht gehen: ein Admin kann zwar alles, aber nicht alles heimlich und folgenlos - daher kann er auf Dateien eines Users nicht einfach zugreifen, aber er kann sie sich aneignen; dann kann aber der User feststellen, dass der Admin sich die Dateien gekrallt hat.

Aus dem gleichen Grund kann ein Admin nicht einfach anstelle eines Users handeln, ohne dessen Passwort zu wissen. Der user kann also sicher sein, dass niemand heimlich an seiner Stelle etwas manipuliert, solange er sein Passwort niemandem verrät. Der Admin kann deshalb ja auch das Passwort nicht lesen, sondern nur löschen, dann weiss aber der User Bescheid.

Für Installationsarbeiten ist das durchaus hinderlich, aber es ist eben Absicht, den Admin nicht allmächtig zu machen. Installation auf User-Ebene ist zwar eine Möglichkeit, aber in Grossfirmen auch nicht gern gesehen oder ganz unterbunden oder verboten - und ausserdem recht mühsam, wenn mehrere User an einem PC arbeiten.

An roaming profiles hat bei diesem Thread auch noch keiner gedacht.

Gruss Reinhard

**H4ndy**

Hallo Reinhard,

Sehr interessante Ansichtsweise und Informationen. Das Problem, was du ansprichst verstehe ich, allerdings dachte ich, dass es da im Kontext der UAC-Elevation nicht doch eine Möglichkeit gibt wieder vom UAC-Admin-Status zurück zum aktuellen Nutzer zu wechseln, da dieser ja während der gesamten Zeit weiterhin am PC angemeldet ist.

**Elvis**

Zitat von Luckie:

Zitat von Elvis:

Nur mal als ein Ansatzpunkt (oder 3)

Der Knackpunkt: Warum braucht der Update-Mechanismus überhaupt erhöhte Privilegien?

Weil das zu aktualisierende Programm in einem Ordner installiert wurde, in dem nur der Administrator Schreibrechte hat, wie es sich auch gehört.

Natürlich hat die Katze da Löcher im Fell wo sich zufällig auch die Augen befinden...
Ich hatte die 3 Punkte eiegentlich als Liste formuliert, damit man sieht was zusammen gehört.

Die App braucht Admin-Rechte, weil sie in einem Ordner liegt, der globale Asuwirkungen hat.
In fast allen Fällen sollte es möglich sein, die App nur pro-User zu installieren. Und zwar indem man sie eben in das User-Profil installiert.
Dadurch gäbe es von vornherein keine Zickereien. Weder mit der UAC noch mit den lokalen IT'lern beim Kunden, die ein weiteres Ärgernis auf ihrer Liste haben.

**H4ndy**

Zitat von Elvis:

Die App braucht Admin-Rechte, weil sie in einem Ordner liegt, der globale Asuwirkungen hat.
In fast allen Fällen sollte es möglich sein, die App nur pro-User zu installieren. Und zwar indem man sie eben in das User-Profil installiert.

Nein, die Anwendung braucht Adminrechte, da sie in einem Ordner rumhantiert, der Adminrechte benötigt (C:\Programme\). Wo die EXE letztendlich liegt ist Windows egal. Und das lässt sich nicht umgehen, wenn man ein installiertes Programm ändern/updaten will. Wäre ja Schwachsinn anzufangen, Programme nach ProgramData\User\Blubb zu installieren, da das ja die gesamte Admin-User-Beziehung praktisch auflöst.

**Elvis**

Zitat von H4ndy:

Zitat von Elvis:

Die App braucht Admin-Rechte, weil sie in einem Ordner liegt, der globale Asuwirkungen hat.
In fast allen Fällen sollte es möglich sein, die App nur pro-User zu installieren. Und zwar indem man sie eben in das User-Profil installiert.

Nein, die Anwendung braucht Adminrechte, da sie in einem Ordner rumhantiert, der Adminrechte benötigt (C:\Programme\). Wo die EXE letztendlich liegt ist Windows egal. Und das lässt sich nicht umgehen, wenn man ein installiertes Programm ändern/updaten will. Wäre ja Schwachsinn anzufangen, Programme nach ProgramData\User\Blubb zu installieren, da das ja die gesamte Admin-User-Beziehung praktisch auflöst.

Naja, es wäre %APPDATA%\Apps\...
Die IT hat weiterhin die Möglichkeit einzugreifen, da die Software in den Reports über instalierte SW auftaucht.
Aber wenn Installationen generell nicht verboten sind sollte es möglich sein.
Wenn die jeweilige Firmenpolitik bei einzelnen Usern jegliche Setups verbietet, wäre man wieder bei dem Falle der UAC angelangt. Aber für alle anderen hat man eine Menge Stress für die IT und den User verhindert.

Microsoft selbst presst für diese Art von Setup. Schließlich ist "Click-Once" standardmäßig pro User.

Ich will hier auch nicht ewig weiter auf dem toten Pferd rumtreten. Der erste Punkt in meiner Liste oben könnte dein Problem lösen.
Aber ein Pro-User Setup könnte (je nach Art der App vielleicht sinnlos) alle möglichen Probleme, auch für den User, lösen.

Bleistift:
19:21 Uhr, User X bekommt von seinem Kunden/Partner Y einen Link der auf einen Client zu irgendeinem einem Webservice zeigt, mit dem er sich schnell die nötigen Reports generieren lassen und irgendwelche noch dringenderen Daten erfassen kann.
Aber *piep* ist, das Client-Setup will Admin-Rechte und der letzte aus der IT ist seit 17:30 Uhr im Feierabend. Schöne *piep* aber auch...

21:10: Endlich einen IT'ler rangekriegt, der (sichtlich angepisst), per RDP das Ding installiert hat.
Du hast jetzt mindestens 2 Leute, von deren Liste sympathischer SW-Schmieden du soeben gestrichen wurdest...