[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:

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:

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:

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:

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:

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:

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:

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:

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:

Zitat von Luckie

Zitat:

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:

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:

Zitat von H4ndy

Zitat:

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...

[Luckie]

Das heißt, du würdest es beführworten, wenn sich jeder Benutzer des Computers die Software in seinem benutzerprofil installiert? Bei, sagen wir, fünf Benutzern also fünf Office Installationen, fünf mal die Entwicklungsumgebeungen usw?

[jaenicke]

Zumal man sich dadurch auch genau wieder den Mist einhandelt, den man vorher hatte. Jeder kleine Virus oder irgendein verbuggtes Programm kann einfach auf andere Exen von anderen Programmen zugreifen und diese manipulieren. Weil man in den Anwendungsdaten ja keine Adminrechte braucht.

Genau so ein Durcheinander wird ja dadurch verhindert, dass man eben genau nicht einfach ohne Adminrechte aufs Verzeichnis der Programme zugreifen kann. Und wenn man einem Virus Adminrechte gibt, dann ist man letztlich selbst schuld, wenn es sich auch unter c:\programme einnistet...

Dass es wie Luckie geschrieben hat, auch Speicherplatzverschwendung ist, kommt noch dazu.

[Elvis]

Zitat:

Zitat von Luckie

Das heißt, du würdest es beführworten, wenn sich jeder Benutzer des Computers die Software in seinem benutzerprofil installiert? Bei, sagen wir, fünf Benutzern also fünf Office Installationen, fünf mal die Entwicklungsumgebeungen usw?

Ich ignoriere im Rest es Beitrages mal einfach, dass du wieder ignorierst hast, dass ich eben NICHT pauschal für ALLE Apps sprach..

Zitat:

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.

Wir haben bei uns in der Firma Citrix XenApps für internen Gebrauch eingeführt.
Nun hat jeder User eine Sandbox pro App. Sogar Office 2007 wird hier auf die Art verteilt.
Wobei hier der Vorteil darin liegt eine App nur einmal installieren zu müssen, und da diese Installation durch einen Monitor läuft, kann man auch das dämlichste Setup gerade biegen und einfach das Ergebnis sooft verteilen wie man Lizenzen hat.
Wir haben hier alte (nicht unsere) Legacy Apps, die auf die Art ihren eigenen Oracle 9 Client, spezielle Versionen von einer COM-lib, etc. kriegen, aber das sieht kein anderer Prozess.
Okay, die Sandbox sieht ihre eigene Version der lokalen Platten, und hat auch nur sehr begrenzten Zugriff. (@Virenschleuder)
Unterm Strich war das eine Entscheidung von der IT, damit keine Zeit mit den Zickereien von Setups auf jedem 10. Client verschleudert wird.

Und der Platz auf der HDD ist doch nun wirklich schnurz piepe. Die Otto-Normal-Workstation hat doch etwa 90% freien HDD Speicher.
Mit vielleicht 20 MB an lokalen Daten, die tatsächlich vom User geschrieben werden (app settings, browser cache, ...).

Zitat:

Zitat von jaenicke

Zumal man sich dadurch auch genau wieder den Mist einhandelt, den man vorher hatte. Jeder kleine Virus oder irgendein verbuggtes Programm kann einfach auf andere Exen von anderen Programmen zugreifen und diese manipulieren. Weil man in den Anwendungsdaten ja keine Adminrechte braucht.

Das kann ein Punkt sein. Wobei ich meine Clients mit der geringst möglichen CAS Zone laufen lasse. Normalerweise "Internet". Und wenn die IT das forcieren möchte, könnte sie User-level setups auf Click-once mit Internet Zone beschränken.
Für native (Delphi) Apps muss das sicherlich abgewogen werden.
Auf das Setup der App zu vertrauen um sicher zustellen dass nix böses drauf kommt ist allerdings etwas ... witzlos.
Du machst ja keine IT-Firmenpolitik mit deiner App und deinen Setups. Das machen die Firmen, die sie einsetzen.

Zitat:

Dass es wie Luckie geschrieben hat, auch Speicherplatzverschwendung ist, kommt noch dazu.

Das war ein Thema als Gigabytes auf der HDD noch volle €-Beträge kosteten.

Ohoh, da habe ich wieder eine Offtopic-Zickerei losgetreten...
Der OP kann sein Problem über IPC lösen. Aber wenn es seine App zulässt, könnte er es halt auch anders lösen.

[Dezipaitor]

Zum Thema:

In Vista, wenn als Admin gestartet, kannst du das LinkedToken vom aktuellen Token nutzen und damit den neuen Prozess starten. Der Prozess läuft dann ohne Adminrechte. Wenn UAC aus ist, dann geht das nicht.
Natürlich kriegst du auch den User über WTSQuerUserToken(-1). Wenn die Funktion statisch gelinkt ist, dann funkz das Prog nicht in Win2000 Wrkst.
Das alles mit CreateProcessAsUser