Vista: Ein Programm mit Benutzerrechten starten

[Stephan]

Guten Tag,

Ich habe folgendes Problem: Ich möchte aus meinem Programm (welches mit Adminrechten läuft), ein anderes Programm mit den Benutzerrechten des aktuell eingeloggten Benutzers starten. Wie ist sowas möglich? Geht dies vielleicht über einen speziellen Parameter via ShellExecute?

Danke im Voraus!

[SirThornberry]

Hier findest du die Antwort Aktion mit anderen User rechten ausführen

[Stephan]

Hallo Jens,

Den Thread hatte ich schon gesehen. Wenn ich das aber richtig sehe, muss dafür das Programm die Zugangsdaten des Administrators kennen oder? (das Programm kennt a ber keinerlei Zugangsdaten von irgendeinem Windows Benutzer) Gibt es nicht einen einfacheren Weg, den anderen Benutzernamen schon im ShellExecute zu übergeben?

Die andere Sache ist natürlich, wie ermittel ich mit welchem Benutzer ich gerade eingeloggt bin, wenn der Prozess der dies ermitteln soll, unter einem anderen Benutzer (Admin) gestartet wurde?

Kurz nochmal mein Programm:
programm.exe (läuft unter dem aktuell eingeloggten Benutzer) startet für ein automatisches Update die update.exe mit Adminrechten. Diese downloadet das Update und installiert dieses. Anschließend soll die programm.exe mit den alten Benutzerrechten wieder gestartet werden (auf keinen Fall soll diese Datei Adminrechte erben).


Kurz gesagt: Ich muss aus meiner Anwendung eine andere .exe unter fremden Rechten starten, ohne hierfür irgendwelche Windows Kennwörter kennen zu müssen. (die Anwendung läuft aber schon unter Administratorrechten).

[alcaeus]

Machs ueber 3 Ecken: programm.exe startet update.exe. update.exe startet do_update.exe mit Adminrechten und wartet bis dieses beendet ist. update.exe startet programm.exe (natuerlich mit Benutzerrechten) und die Sache ist gegessen. Nicht schoen, aber wirkt ;)

Greetz
alcaeus

[Stephan]

Hallo Andreas,

Danke für dein Posting. Das würde zwar funktionieren, ist aber (wie ich finde) eine doch sehr unschöne Lösung. Ist das denn die einzige Möglichkeit?

[CodeX]

Zitat:

Zitat von Stephan

Kurz gesagt: Ich muss aus meiner Anwendung eine andere .exe unter fremden Rechten starten, ohne hierfür irgendwelche Windows Kennwörter kennen zu müssen.

Unter fremden Rechten? Das wird ohne Benutzernamen+Passwort kaum gehen. Und nach logischem Überlegen ist das generell gesehen auch gut so.

Zitat:

Zitat von Stephan

programm.exe (läuft unter dem aktuell eingeloggten Benutzer) startet für ein automatisches Update die update.exe mit Adminrechten. Diese downloadet das Update und installiert dieses. Anschließend soll die programm.exe mit den alten Benutzerrechten wieder gestartet werden (auf keinen Fall soll diese Datei Adminrechte erben).

1. programm.exe ruft update.exe auf
2. update.exe prüft, ob es adminrechte hat, falls nicht, startet es sich mit verschlüsselt gespeicherten admin-anmelde-daten neu und beendet die laufende instanz.
3. update.exe hat adminrechte und macht das update.
4. update.exe sendet ein signal an programm.exe und beendet sich selber
5. programm.exe erhällt signal und startet sich selbst neu und beendet die laufende instanz.

sollte imho so gehen.

Zitat:

Zitat von Stephan

Die andere Sache ist natürlich, wie ermittel ich mit welchem Benutzer ich gerade eingeloggt bin, wenn der Prozess der dies ermitteln soll, unter einem anderen Benutzer (Admin) gestartet wurde?

Das wüsste ich auch gerne.

[Stephan]

Zitat:

Und nach logischem Überlegen ist das generell gesehen auch gut so.

Warum? Dass dies als Standardbenutzer nicht gehen darf, das ist klar. Aber als Admin habe ich doch schon (fast) die höchsten Rechte. Unter Linux geht das ja auch, wenn ich root bin kann ich mit "su" auch ohne Benutzerkennwort mich unter jedem anderen Benutzeraccount anmelden :)

[alcaeus]

Zitat:

Zitat von CodeX

2. update.exe prüft, ob es adminrechte hat, falls nicht, startet es sich mit verschlüsselt gespeicherten admin-anmelde-daten neu und beendet die laufende instanz.

Autsch. Der Benutzer muss wenn schon sein Passwort eingeben, gespeichert wird da nichts.

Greetz
alcaeus

[CodeX]

Zitat:

Zitat von alcaeus

Zitat:

Zitat von CodeX

2. update.exe prüft, ob es adminrechte hat, falls nicht, startet es sich mit verschlüsselt gespeicherten admin-anmelde-daten neu und beendet die laufende instanz.

Autsch. Der Benutzer muss wenn schon sein Passwort eingeben, gespeichert wird da nichts.

Warum?
Wenn das ganze automatisiert werden soll, dann kann man den Benutzer die Daten ein Mal eingeben lassen, diese verschlüsselt speichern und dann bei Bedarf darauf zurückgreifen.
(Klar, ist in gewisser Weise ein Sicherheitsrisiko, aber ich sag mal so: gib mir deinen PC für nen Tag und ich sag dir alle deine Windows Passwörter. ;))

Zitat:

Zitat von Stephan

Zitat:

Und nach logischem Überlegen ist das generell gesehen auch gut so.

Warum? Dass dies als Standardbenutzer nicht gehen darf, das ist klar. Aber als Admin habe ich doch schon (fast) die höchsten Rechte. Unter Linux geht das ja auch, wenn ich root bin kann ich mit "su" auch ohne Benutzerkennwort mich unter jedem anderen Benutzeraccount anmelden :)

Mal abgesehen davon, dass ichs dann trotzdem nicht richtig finden würde, würde es helfen, wenn du dich entscheiden würdest, ob dein Hauptprogramm Adminrechte hat oder nicht. Denn mit Adminrechten sowohl bei programm.exe als auch bei update.exe gibt es doch keine Schwierigkeiten!?

[OregonGhost]

Hmm, man kann doch im Manifest festlegen, dass update.exe mit Admin-Rechten laufen will. Kann man dann nicht auch im Manifest von programm.exe festlegen, dass es bei nur vererbten Admin-Rechten diese nicht benutzen soll? Oder ist kein Rücksprung möglich auf den Benutzer?

[Stephan]

Hallo,

Hm, ich hab nen interessanten Weg gefunden. Wenn ich einfach per ShellExecute nicht direkt die Programmdatei sondern einfach eine Verknüpfung zu dieser Programmdatei starte, dann erbt der neu gestartete Prozess NICHT die Adminrechte, sondern die normalen Benutzerrechte :)

Dies ist zwar ziemlich Dirty, scheint aber zu funktionieren ... :D (wobei ich hier über jede schönere Lösung dankbar bin)

[Stephan]

Ok, merkwürdigerweise scheint der Trick mit der Verknüpfung nicht mehr zu funktionieren - dabei hätte ich schwören können, dass das vorhin mehrmals erfolgreich ging :freak:

[ol1uw]

Folgendes habe ich mal verwendet um von einen Programm ,welches mit Systemrechten läuft, eine Anwendung
zustarten als aktueller User.
Keine Ahnung ob es unter Vista geht (nur unter XP getestet) und ob es in deinem Fall brauchbar ist.

Delphi-Quellcode:

program csfax;

uses
   Windows,  SysUtils, Dialogs,
   tlhelp32,registry;
{$R *.res}

var
  Reg: TRegistry;
  fax: string;
  prog: string;
  hToken, pToken: Cardinal;
  bResult: Boolean;
  pi: TProcessInformation;
  si: TStartupInfo;
  proctoken, Procid: Cardinal;

  function GetProcessID(Exename: string): DWORD;
  var
    hProcSnap: THandle;
    pe32: TProcessEntry32;
  begin
    result := 0;
    hProcSnap := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
    if hProcSnap <> INVALID_HANDLE_VALUE then
    begin
      pe32.dwSize := SizeOf(ProcessEntry32);
      if Process32First(hProcSnap, pe32) = true then
      begin
        while Process32Next(hProcSnap, pe32) = true do
        begin
          if pos(UpperCase(Exename),Uppercase( pe32.szExeFile)) <> 0 then
            result := pe32.th32ProcessID;
        end;
      end;
      CloseHandle(hProcSnap);
    end;
  end;

begin
  reg := TRegistry.Create;
  reg.RootKey := LongWord($80000002);
  try
    reg.OpenKey('SYSTEM\CurrentControlSet\Control\Print\Monitors\CsFax Port Monitor', False);
    fax := ' FAX "';
    fax := fax + reg.ReadString('SpoolDatei');
    fax := fax + '"';
    reg.CloseKey;
    reg.OpenKey('SOFTWARE\Komclient\Fax', False);
    prog := reg.ReadString('InstallDir');
    reg.CloseKey;
  finally
    reg.Free;
  end;

  Procid := GetProcessID('EXPLORER.EXE');
  proctoken := OpenProcess(PROCESS_ALL_ACCESS, true, Procid);
  bResult := OpenProcessToken(proctoken, TOKEN_DUPLICATE or TOKEN_IMPERSONATE,hToken);
  if not bResult then 
    ShowMessage('Prozess Token :' + SysErrorMessage(GetLastError));
  bResult := DuplicateTokenEx(hToken, TOKEN_ALL_ACCESS, nil,SecurityImpersonation, TokenPrimary,pToken);
  if not bResult then
    ShowMessage('Duplicate Token : ' + SysErrorMessage(GetLastError));

  with si do
  begin
    cb := SizeOf(TStartupInfo);
    lpReserved := nil;
    lpDesktop := nil;
    dwX := 0;
    dwY := 0;
    dwXSize := 0;
    dwYSize := 0;
    dwXCountChars := 0;
    dwYCountChars := 0;
    dwFillAttribute := 0;
    dwFlags := 0;
    wShowWindow := SW_SHOWDEFAULT;
    cbReserved2 := 0;
    lpReserved2 := nil;
    hStdInput := 0;
    hStdOutput := 0;
    hStdError := 0;
  end;
  bResult := CreateProcessAsUser(
    pToken,
    nil,
    PChar(prog+fax),
    nil,
    nil,
    False,
    NORMAL_PRIORITY_CLASS,
    nil,
    nil,
    si,
    pi
    );
  if not bResult then
    ShowMessage('CreatProcessASUser : ' + SysErrorMessage(GetLastError));
  CloseHandle(ptoken);
end.

[Stephan]

Hallo,

Danke für deinen Code. Unter Vista erhalte ich leider (auch mit Adminrechten) folgenden Fehler:

CreatProcessASUser: Dem Client fehlt ein erforderliches Recht

[OregonGhost]

Das sieht mir nach einer "but the demo worked"-Lösung aus.
Im Oldnewthing von Raymond Chen müsste dazu mehr zu finden sein... Es gibt nicht den aktuellen Benutzer unter Vista :stupid:

Mal eine andere Frage dazu... wenn man unter Vista Admin ist, starten die Programme dann nicht unter dem Namen des Benutzers, obwohl er keine Admin-Rechte hat?

[Stephan]

Ich hab mal bisschen im MSDN geschaut und folgendes gefunden: CreateProcessWithTokenW http://msdn2.microsoft.com/en-us/library/ms682434.aspx

Das klingt für mich irgendwie richtig. Weiß hier jemand, wie man das in Delphi implementieren muss?

Zitat:

Mal eine andere Frage dazu... wenn man unter Vista Admin ist, starten die Programme dann nicht unter dem Namen des Benutzers, obwohl er keine Admin-Rechte hat?

Die meisten Programme werden wohl auch unter einem Adminkonto nicht mit Adminrechten gestartet.

[ProgrammerJoe]

Zitat:

Delphi-Quellcode:

  function GetProcessID(Exename: string): DWORD;
  var
    hProcSnap: THandle;
    pe32: TProcessEntry32;
  begin
    result := 0;
    hProcSnap := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
    if hProcSnap <> INVALID_HANDLE_VALUE then
    begin
      pe32.dwSize := SizeOf(ProcessEntry32);
      if Process32First(hProcSnap, pe32) = true then
      begin
        while Process32Next(hProcSnap, pe32) = true do
        begin
          if pos(UpperCase(Exename),Uppercase( pe32.szExeFile)) <> 0 then
            result := pe32.th32ProcessID;
        end;
      end;
      CloseHandle(hProcSnap);
    end;
  end;

An mehreren Stellen im Forum geistert immer wieder dieser Codeschnipsel durchs Forum, wenn es darum geht, die Prozess-ID anhand des exe-Namens zu ermitteln (z.B. Suche nach hProcSnap).

Dazu habe ich zwei Fragen:

1. Die Funktion verwendet eine kopfgesteuerte und keine fußgesteuerte Schleife. Das heißt, der erste Prozeß wird nie erfaßt. Ist das irgendein Systemprozeß, den man nicht haben will? Ist das Absicht? Habe ich irgendetwas nicht verstanden, oder ist das schlicht ein Bug?

2. Es wäre sinnvoll, im Erfolgsfall aus der Schleife auch auszusteigen. Ich würde die Funktion daher so schreiben:

Delphi-Quellcode:

  function GetProcessID(Exename: string): DWORD;
  var
    hProcSnap: THandle;
    pe32: TProcessEntry32;
  begin
    result := 0;
    hProcSnap := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
    if hProcSnap <> INVALID_HANDLE_VALUE then begin
      pe32.dwSize := SizeOf(ProcessEntry32);
      if Process32First(hProcSnap, pe32) = true then begin
        repeat
          if pos(UpperCase(Exename),Uppercase( pe32.szExeFile)) <> 0 then begin
            result := pe32.th32ProcessID;
            break;
          end;
        until Process32Next(hProcSnap, pe32) = false;
      end;
      CloseHandle(hProcSnap);
    end;
  end;

Spricht irgendetwas gegen diese Version?

[Dezipaitor]

1. Für die Funktion gibts ein Beispiel :
http://msdn2.microsoft.com/en-us/library/ms686701.aspx
Die nutzen do while
2. natürlich

Übrigens gibt es seit XP die Funktion
WTSQueryUserToken um das Token zu erhalten.
Das funkz auch bei Leuten, die kein Explorer haben.



Noch was:
1. Bedenkt auch die Leute die noch kein Explorer.exe Prozess haben
Das kann passieren wenn:
a) der benutzer ne andere shell nutzt
b) der dienstcode vor der shell geladen wird
c) explorer wurde gekillt
2. wenn es mehrere Sessions gibt - in welche wird der prozess geöffnet? (Fast User Switching, Terminal Session)

[ProgrammerJoe]

Ist der erste Prozess, der zurückgegeben wird, denn tatsächlich immer die explorer.exe?

do while ist für mich in Delphi return until.

Demnach gehe ich von einem Bug aus, weil jemand die Funktion falsch nach Delphi übersetzt hat.

Es wundert mich, daß so viele Leute den Code nutzen und posten, aber niemandem das aufgefallen ist.

Ist er schon irgendwo in der Codelibrary? Vielleicht könnte man eine Anmerkung dort mit Verweis auf diesen Thread machen, wobei ich zugeben muss, dass der Titel zu diesem Problem vielleicht nur bedingt paßt.

[Dezipaitor]

Hmm

ich hab jetzt noch bei SwissDelphiCenter geguckt, und die scheinen korrekt zu sein.

http://www.swissdelphicenter.ch/de/showcode.php?id=593
http://www.swissdelphicenter.ch/de/showcode.php?id=266

[ProgrammerJoe]

noch ein Hinweis, wenn jemand diesen Code verwenden möchte:

Auf manchen Systemen, wie ich zum Beispiel heute im Terminalserver festgestellt habe, werden zum Beispiel bei den Prozessnamen ab dem 15. Zeichen alle weiteren abgeschnitten, daher würde es sich empfehlen, Suchpattern und Suchort in der pos()-Funktion zu vertauschen und aus folgender Zeile:

Delphi-Quellcode:

if pos(UpperCase(Exename),Uppercase(pe32.szExeFile)) <> 0 then begin

folgendes zu machen:

Delphi-Quellcode:

if pos(Uppercase(pe32.szExeFile), UpperCase(Exename)) <> 0 then begin

Demnach müßte der Code so lauten:

Delphi-Quellcode:

function GetProcessID(Exename: string): DWORD;
  var
    hProcSnap: THandle;
    pe32: TProcessEntry32;
  begin
    result := 0;
    hProcSnap := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
    if hProcSnap <> INVALID_HANDLE_VALUE then begin
      pe32.dwSize := SizeOf(ProcessEntry32);
      if Process32First(hProcSnap, pe32) = true then begin
        repeat
          if pos(Uppercase(pe32.szExeFile), UpperCase(Exename)) <> 0 then begin
            result := pe32.th32ProcessID;
            break;
          end;
        until Process32Next(hProcSnap, pe32) = false;
      end;
      CloseHandle(hProcSnap);
    end;
  end;

[Olli]

Zitat:

Zitat von ProgrammerJoe

Auf manchen Systemen, wie ich zum Beispiel heute im Terminalserver festgestellt habe, werden zum Beispiel bei den Prozessnamen ab dem 15. Zeichen alle weiteren abgeschnitten [...]

Auf allen Windows-NT-Systemen, wohlgemerkt. Im Kernel wird im Prozeßobjekt der Name eben nur mit sovielen Zeichen *und* nur in ANSI gespeichert. Daher ist es besser den Namen mit der PSAPI zu ermitteln, weil die ToolHelp-API auf der Native-API aufsetzt, welche die Daten des Prozeßobjektes "einfach" nur kopiert. Soweit ich weiß macht die PSAPI das anders, nämlich durch Kopieren der Info aus dem Prozeß selbst (CreateRemoteThread & Co.).