fehlende Rechte nach EXE start auf WIN7

[ZOD]

Hallo zusammen,

ich bin nicht sicher, ob dies hier die richtige Rubrik ist ..

Ich habe:
(1) Eine Startroutine zur aktualisierung einer lokalen Installation meines Programmes,
Diese ist mit einem Manifest ausgestattet, so daß diese mit Admin-Privilegien gestartet wird. --> Das klappt, die Startroutine kopiert evt. Updates problemlos ohne Fehler.

(2) Ein Programm, welche von der Startroutine (nach dem Updaten) mittels CreateProcess gestartet wird --> das klappt auch. Nach dem Start des Programmes wird die Startroutine (1) beendet.
Beim CreateProcess sind die process security attributes und thread security attributes
jeweils nil, also müsste ich die Sicherheitsrichtlinien der Startroutine für das neue gestartete Programm übernehmen.

Nun das Problem:
Wenn auf einem Win7 Rechner jedoch das Programm (2) auf eine Datei mit den Attributen versteckt und schreibgeschützt zugreifen möchte, so klappt das nicht ("Datei nicht gefunden").
Wird das Programm (2) direkt durch einen Doppelklick gestartet, geht alles wunderbar.
Ebenfalls problemlos ist der Programmstart auf XP Rechner.
Ob eine Datei da ist oder nicht prüfe ich mittels GetFileAttributes wie z.B. in
http://www.delphipraxis.net/153617-f...st.htmlhttp://
beschrieben.

Mir scheint es so zu sein, daß beim Programmstart über die Startroutine der Benutzerkontext
und damit die Berechtigungen verschwinden - allerdings nur bei Win7.
Liegt es daran, daß die Startroutine beendet wird und dadurch dieser Kontext verschwindet?
Wenn ja - wie starte ich das Programm dann ohne dieses Problem aus der Startroutine heraus?

Hat jemand einen Vorschlag, wie ich der Sache auf den Grund gehen kann? Danke.

Ach ja: Ich arbeite hier mit D7

[jaenicke]

Wie sieht denn dein CreateProcess aus?

Ich vermute ein Pfadproblem.

Worauf genau da versucht wird zuzugreifen usw. siehst du am einfachsten im Process Monitor von Sysinternals / Microsoft.

[ZOD]

Guten Morgen Jaenicke,

den Aufruf von CreateProcess habe ich hier abgeguckt:

http://www.delphi-treff.de/tipps/sys...createprocess/

Bei mir sieht das so aus:

Delphi-Quellcode:

procedure TRMGlobFuncUniversal.ExecuteFile(
  const AFilename: String;
  AParameter, ACurrentDir: String;
  AWait: Boolean;
  AOnWaitProc: TExecuteWaitEvent);
var
  si: TStartupInfo;
  pi: TProcessInformation;
  bTerminate: Boolean;
  lokParameter,
  lokFilename : string;
begin
  bTerminate := False;

  if Length(ACurrentDir) = 0 then
    ACurrentDir := ExtractFilePath(AFilename);

  if AnsiLastChar(ACurrentDir) = '\' then
    Delete(ACurrentDir, Length(ACurrentDir), 1);

  FillChar(si, SizeOf(si), 0);
  with si do begin
    cb := SizeOf(si);
    dwFlags := STARTF_USESHOWWINDOW;
    wShowWindow := SW_NORMAL;
  end;

  FillChar(pi, SizeOf(pi), 0);

  lokParameter := Trim(AParameter);
  lokFilename := Trim(AFilename); // Format('"%s"', [AFilename]);
  AParameter := Format('"%s" %s', [AFilename, TrimRight(AParameter)]);

  if CreateProcess(
    // Nil,  PChar(AParameter),
    PChar(lokFilename),  // pointer to name of executable module
    PChar(''),           // pointer to command line string
    Nil,                 // pointer to process security attributes
    Nil,                 // pointer to thread security attributes
    False,               // handle inheritance flag
    CREATE_DEFAULT_ERROR_MODE or CREATE_NEW_CONSOLE or NORMAL_PRIORITY_CLASS,  // creation flags
    Nil,                 // pointer to new environment block
    PChar(ACurrentDir),  // pointer to current directory name
    si,                  // pointer to STARTUPINFO
    pi                   // pointer to PROCESS_INFORMATION
    ) then
  try
    if AWait then
      while WaitForSingleObject(pi.hProcess, 50) <> Wait_Object_0 do
      begin
        if Assigned(AOnWaitProc) then
        begin
          AOnWaitProc(pi, bTerminate);
          if bTerminate then
            TerminateProcess(pi.hProcess, Cardinal(-1));
        end;

        Application.ProcessMessages;
      end;
  finally
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
  end;
end;

Die Funktion liegt in einer Singelton Unit und wird auch für andere Zwecke verwendet.
Der Aufruf sieht so aus:

Delphi-Quellcode:

RMFuncUniversal.ExecuteFile(PfadPASExeLok, '', ExtractFilePath(PfadPASExeLok), False, nil);

wobei PfadPASExeLok als Property in der aufrufenden Unit definiert ist:

Delphi-Quellcode:

property PfadPASExeLok : string read FPfadPASExeLok write FPfadPASExeLok;

Der Pfad zur EXE ist korrekt, das Programm wird auch gestartet. Es gibt eben dann
nach dem Aufruf de Programmes aus der Startroutine heraus im Programm bei Dateizugriff
den Fehler "Datei nicht gefunden".

Die Dateien, auf die zugegriffen wird, liegen auf einem Netzwerklaufwerk und sind Teil eines
Archivsystems. Der Pfad wird aus einer Datenbank (FB2.5) ausgelesen und ist dort "hart" incl.
LW-Buchstaben belegt. Die entsprechende Netzwerkverbindung ist angemeldet und funktioniert,
das ist schon daran zu erkennen, daß bei einem Direktaufruf (Doppelklick auf die EXE)
das ganze fehlerfrei läuft.

[jaenicke]

Zitat:

Zitat von ZOD (Beitrag 1232686)

Der Pfad zur EXE ist korrekt, das Programm wird auch gestartet. Es gibt eben dann
nach dem Aufruf de Programmes aus der Startroutine heraus im Programm bei Dateizugriff
den Fehler "Datei nicht gefunden".

Ich rate mal:
Die Exe liegt unter c:\program files bzw. c:\programme? Und der Pfad, den du nutzt, lautet c:\programme\...?
Da c:\programme auf c:\program files umgeleitet wird, funktioniert der Start durchaus. Eigene Dateizugriffe aber nicht. Kann das so etwas sein?

Wenn das Delphi 7 bereits unterstützt, kannst du in den Debugger-Optionen die Option "Debug in Spawned-Prozessen" aktivieren um nach dem Start der Exe weiter zu debuggen.
Alternativ kannst du auch die Exe mit externen Debugsymbolen kompilieren und dich dann mit "Start --> Mit Prozess verbinden..." mit dem Debugger einklinken. Dafür ist es am einfachsten direkt nach das begin in der .dpr Projektdatei diese Zeilen einzufügen und danach einen Haltepunkt zu setzen:

Delphi-Quellcode:

while not IsDebuggerPresent do // Unit Windows wird benötigt
  Sleep(100);

Wenn das alles nicht funktioniert, bleiben noch Process Explorer um das Arbeitsverzeichnis usw. zu prüfen und der Process Monitor um die Dateizugriffe zu sehen und zu prüfen.

[sx2008]

gelöscht

[ZOD]

Ich bin nicht sicher, ob wir hier wirklich ein Pfadproblem haben.

Hier nochmals das "Kondensat" der Umgebung

(a) OS <= WinXP
Die Startroutine liegt auf einem Netzpfad und kopiert
die notwendigen Programmdateien lokal. Dabei wird zwar
auch u.U. einiges in das Windowsverzeichnis kopiert
(z.B. DLL), aber das eigentliche Programm kommt in
das Programmverzeichnis - meist also in

C:\Programme\RMPAS

Von dort wird es auch im CreateProcess gestartet (property PfadPASExeLok).

(b) Win7 64bit
Wie bei (a) liegt die Startroutine im Netz.
Damit das Kopieren funktioniert wird diese mit Admin Rechten
aufgerufen (Manifest). Das Kopieren klappt auch problemlos.
Das eigentliche Programm liegt dann (typischer Weise) in

C:\Program Files (x86)\RMPAS

und wird von dort auch gestartet. Beim Belegen des Properties PfadPASExeLok
wird mittels SHGetSpecialFolderLocation und CSIDL_PROGRAM_FILES der
Programmpfad vom System abgefragt und dann um das Installationsverzeichnis
der Anwendung erweitert (\RMPAS).

Das Debuggen muß ich noch ausprobieren.
Aus oben genanntem Zusammenhang heraus ich bin jedoch skeptisch, ob ich hier fündig werden.

Irgendwie kennt Win7 beim Aufruf der Exe aus der Startroutine heraus die Benutzerrechte bzw.
die Netwerkpfade nicht mehr ...

[jaenicke]

Ja, den Zusammenhang, dass du eingangs von Adminrechten gesprochen hast und beim letzten Post von Netzwerkpfaden hatte ich übersehen. :oops:

Es ist so, dass ein Programm ebenfalls Adminrechte hat, wenn es von einem anderen Programm mit Adminrechten gestartet wird. Netzlaufwerke sind aber im Adminkontext nicht vorhanden, wenn sie nicht auch für das Admintoken des Users angelegt sind.

Deshalb machen eigentlich alle Update oder Installationsprogramme das so, dass die Anwendung danach mit normalen Rechten gestartet wird.

Ich selbst habe das in meinem (leider nicht mehr weiterentwickelten) in die Anwendung integrierten Updater so gemacht, dass diese kein Adminmanifest enthält, sondern sich selbst als Admin neu startet, aber selbst weiter läuft. Die Admininstanz benennt die Exe nur um, legt die neue Version dort hin und diese wird dann von der ursprünglichen Instanz ohne Adminrechte wieder im selben Benutzerkontext gestartet. (Dann wird die ursprüngliche Instanz beendet und die Admininstanz löscht die umbenannte alte Version.)

Normale Installer machen das natürlich anders, diese ermitteln den Benutzerkontext und starten die Anwendung mit diesen Privilegien. In Inno Setup solltest du sehen können wie das geht, das ist ja Open Source.

[Dalai]

Noch allgemeiner formuliert: Netzlaufwerke sind seit Windows XP nutzerspezifisch (bei Win2k zwar ebenfalls, aber noch nicht so strikt getrennt wie bei XP+). D.h. jeder Nutzer hat seine eigenen Netzlaufwerke, so dass man bei Geschichten wie RunAs darauf achten muss. Das wäre dir übrigens auch aufgefallen, wenn du den Nutzerwechsel unter XP ebenfalls gemacht hättest - was nebenbei gesagt eine gute Idee wäre, denn momentan liest sich das so, als gingest du davon aus, dass der Nutzer Adminrechte hat...

MfG Dalai

[ChrisE]

Zitat:

Zitat von Dalai (Beitrag 1232729)

Noch allgemeiner formuliert: Netzlaufwerke sind seit Windows XP nutzerspezifisch (bei Win2k zwar ebenfalls, aber noch nicht so strikt getrennt wie bei XP+). D.h. jeder Nutzer hat seine eigenen Netzlaufwerke, so dass man bei Geschichten wie RunAs darauf achten muss. Das wäre dir übrigens auch aufgefallen, wenn du den Nutzerwechsel unter XP ebenfalls gemacht hättest - was nebenbei gesagt eine gute Idee wäre, denn momentan liest sich das so, als gingest du davon aus, dass der Nutzer Adminrechte hat...

MfG Dalai

Hmm - also eigentlich ist es noch ne Ecke härter. Seit Windows Vista kann der Benutzer Adminrechte haben aber Prozesse laufen trotzdem ohne diese Rechte (Stichwort UAC). Hebt der Anwender jetzt unter Windows Vista / 7 einen Prozess in seinem eigenen Namen auf Adminrechteebene (selber USER!) - existieren die Netzlaufwerke noch sind aber nicht verbunden. Seit Windows 8 gibt es nicht mal mehr die Netzlaufwerke auf der Adminrechte-Ebene des selben Benutzers.

Aber das ist glaube ich nicht das Problem hier.

Gruß, Chris

[EDIT]
Is doch immer mal wieder gut, sein vermeintliches Wissen zu überprüfen. Die Aussage bzgl. Windows 8 / 8.1 stimmt nur wenn man die Netzlaufwerke per WNetEnumResource macht. Prüft man hingegen hart jeden Laufwerksbuchstaben durch mit WNetGetConnection scheint es die Verbindungen zu geben? Warum ist mir im Augenblick noch völlig unklar :shock:
[/EDIT]

[ZOD]

Danke für die Tipps an alle.

@Dalai
ich hatte bereits Nutzerwechsel im XP und im Win7 und unter W2K (ja - das tuckert auch noch manchmal :wink:) gemacht.
Ergebnis: es gibt nur beim Win7 das geschilderte Problem.

Mittels procexp.exe habe ich nun mir die Properties der EXE nach dem Aufruf aus der
Startroutine heraus angeschaut und mit denen nach Aufruf per Doppelklick verglichen.

Ergebnis:

a) in beiden Fällen ist der richtige User angegeben.
@Dalai: dies gilt auch nach Userwechsel für unterschiedliche User.

b) beim Aufruf per Doppelklick ist als Parent "explorer.exe" angegeben,
beim Aufruf aus der Startroutine ist als Parent die Exe der Startroutine angegeben.

Wenn man den Startvorgang im procexp.exe beobachtet "hängt" die Programm-Exe als Prozess zuerst
unter dem Prozess der Startroutine. Dann beendet sich die Startroutine und die
Programm-Exe ist auf die oberste Ebene der Prozesshirachie verschoben.

Ich würde daher gerne die Programm-Exe aus der Startroutine mit dem parent
"explorer.exe" starten.
Kann mir jemand sagen, wie das gehen könnte?
Danke.

[jaenicke]

Zitat:

Zitat von ZOD (Beitrag 1232775)

Ich würde daher gerne die Programm-Exe aus der Startroutine mit dem parent
"explorer.exe" starten.

Der Parent hat damit nichts zu tun, der ist rein informativ (lässt sich z.B. per WMI abfragen, ist aber auch nicht immer korrekt, z.B. wenn die Prozess ID des Parents schon neu vergeben wurde). Der Benutzerkontext ist das Entscheidende.

[ZOD]

OK, aber der Benutzer ist laut procexp der gleiche.
Dann müsste es mehrere "Benutzerkontexte" pro Benutzer geben,
was ich dann nicht verstehe.

Eigentlich suche ich nun nach einer Möglichkeit, das Programm
aus der Startroutine heraus so zu starten, als ob es per
Doppelklick aus einem Explorerfenster heraus gestartet würde.
Denn dann geht ja alles.

Ist es in diesem Fall besser mit ShellExecut bzw. ShellExecutEx zu arbeiten?
Oder handle ich mir da neue Probleme ein?

[Dalai]

OK, ich versuch's nochmal anders zu erklären: Jeder Benutzer hat eigene Netzlaufwerke, aber auch ein Elevated-Prozess im Falle der UAC hat eigene. Die Netzlaufwerke hängen von einem (Security) Token ab - Elevated-Prozesse haben ein anderes Token als Non-Elevated - völlig unabhängig davon, ob der Benutzer(name) derselbe ist. Das sind dann "mehrere Benutzerkontexte pro Benutzer", wenn du so willst.

MfG Dalai

[musicman56]

Hallo,

aus genau diesem Grund würde ich es mit ShellExecute und dem Verb "runas" probieren. Wenn die Startroutine des Setup dann als Administrator gestartet würde, müssten doch alle von dieser Routine gestarteten Prozesse ebenfalls unter dem Admin-Konto laufen.

[ZOD]

Guten Abend zusammen,

das probiere ich morgen aus und melde dann, wie es geklappt hat.

Danke für heute!

[ZOD]

Ich habe den Programmaufruf aus der Startroutine nun
mit

Delphi-Quellcode:

     ShellExecute(
        0,
        PChar('open'),
        PChar(ProgDateiPfad),
        PChar(ProgParameter),
        PChar(ArbeitsVerzeichnis),
        SW_SHOW
        );

gemacht - das Problem bleibt bestehen. Im procexp bekomme ich
(wie bei CreateProcess auch) den richtigen Benutzer angezeigt.

Wenn ich aus dem gestarteten Programm heraus einen Explorer starte mit

Delphi-Quellcode:

ShellExecute(Application.Handle, 'explore', PChar(Directoryname), nil, nil, SW_SHOWNORMAL);

dann sind die Netzverbindungen zwar da, jedoch die Verzeichnisse mit dem Attribut
"versteckt" werden nicht angezeigt.

Hängt das auch mit dem "(Security) Token" zusammen? Die Einstellung zur
Anzeige von versteckten Dateien wird doch normalerweise im Explorer unter

"Extras|Ordneroptionen|Ansicht|Versteckte Dateien und Ordner"

eingestelt bzw. im entspr. Registry-Schlüssel gespeichert.

Was mache ich hier falsch?

[ChrisE]

Zitat:

Zitat von ZOD (Beitrag 1232893)

...dann sind die Netzverbindungen zwar da, jedoch die Verzeichnisse mit dem Attribut
"versteckt" werden nicht angezeigt...

Aber Moment: Es ist doch unerheblich ob Dateien und Verzeichnis per Attribut versteckt sind.
Ob man sie öffnen kann oder nicht, hängt nur davon ab:

1. Ist der Pfad und Dateiname korrekt
2. Habe ich / der Prozess das Recht die Datei / den Pfad zu öffnen / zu lesen

Ich glaube es wäre an der Zeit zu zeigen:

• wie du die Datei öffnest
• woher die Informationen zum Dateinamen inkl. Pfad kommen
• welche Rechte auf der eigentlichen Zieldatei eingetragen sind

Gruß, Chris

[jaenicke]

Zitat:

Zitat von ZOD (Beitrag 1232893)

Im procexp bekomme ich
(wie bei CreateProcess auch) den richtigen Benutzer angezeigt.

Wie schon geschrieben, es gibt für jeden Benutzer zwei Token, eines mit und eines ohne Adminrechte. Das siehst du am Benutzernamen nicht.

Das siehst du z.B. im Taskmanager in der Spalte Heraufgestuft, ich glaube die gab es auch bei Windows 7 schon.

Du musst den neuen Prozess mit dem normalen Benutzertoken starten wie ich schon geschrieben habe um dessen Rechte zu haben.

[ZOD]

@Chris
Kurzantwort
Der Zugriff auf die Dateien erfolgt mit ShellExecute, die Pfadnamen sind
in einer DB gespeichert mit "hart" vorgegebenen LW-Buchstaben.

Langantwort:
Öffne ich aus dem Programm heraus das Verzeichnis einer der ""Problem-Dateien" mit

Delphi-Quellcode:

ShellExecute(Application.Handle, 'explore', PChar(Directoryname), nil, nil, SW_SHOWNORMAL);

so bekomme ich als Rückgabewert
"5" - also
"Fehler beim gemeinsamen Zugriff auf eine Datei im Netz oder Fehler beim Zugriff auf eine gesperrte Datei im Netz."

Wenn ich dann aus genau dem jetzt laufenden Programm heraus einen Explorer für das EXE-Verzeichnis starte mit

Delphi-Quellcode:

ShowDirectory(ExtractFilePath(Application.ExeName))

Dann kann ich mich darin bis zum ursprünglichen Verzeicnis durchklickern
und bekomme hier auch alle Dateien angezeigt und kann diese per Doppelkklick öffnen.

Die Pfade sind wie geschildert "hart" in einer DB gespeichert, incl. Laufwerksbuchstaben.
(Wir verwenden für einige Server Volumes fest vergebene LW-Buchstaben).

Die Rechte auf die Zieldatei sind da - sonst könnte ich sie ja nicht wie
oben geschildert im aus dem Programm heraus gestarteten Explorer anzeigen.

Für die Anzeige wird ein normales ShellExecute verwendet, zuerst wird
das Programm für die Anzeige über die FileExtension ermittelt und dieses
dann ebenfalls per ShellExecute aufgerufen. Klappt hervorragend bei OS <= XP.

Ich verstehe einfach nicht, warum der Benutzer einmal die Rechte hat und
ein andermal die Rechte nicht hat.

[ZOD]

@jaenicke

Zitat:

Zitat von jaenicke (Beitrag 1232906)

Wie schon geschrieben, es gibt für jeden Benutzer zwei Token, eines mit und eines ohne Adminrechte. Das siehst du am Benutzernamen nicht.

Das siehst du z.B. im Taskmanager in der Spalte Heraufgestuft, ich glaube die gab es auch bei Windows 7 schon.

Du musst den neuen Prozess mit dem normalen Benutzertoken starten wie ich schon geschrieben habe um dessen Rechte zu haben.

wie mache ich das?

[jaenicke]

Wie ich schon schrieb:

Zitat:

Zitat von jaenicke (Beitrag 1232716)

Ich selbst habe das in meinem (leider nicht mehr weiterentwickelten) in die Anwendung integrierten Updater so gemacht, dass diese kein Adminmanifest enthält, sondern sich selbst als Admin neu startet, aber selbst weiter läuft. Die Admininstanz benennt die Exe nur um, legt die neue Version dort hin und diese wird dann von der ursprünglichen Instanz ohne Adminrechte wieder im selben Benutzerkontext gestartet. (Dann wird die ursprüngliche Instanz beendet und die Admininstanz löscht die umbenannte alte Version.)

Normale Installer machen das natürlich anders, diese ermitteln den Benutzerkontext und starten die Anwendung mit diesen Privilegien. In Inno Setup solltest du sehen können wie das geht, das ist ja Open Source.

Wie diese Installer das machen, weiß ich selbst nicht genau. Es gibt zwar CreateProcessAsUser usw., aber damit habe ich mich nie beschäftigt...

[p80286]

Zitat:

Zitat von ChrisE (Beitrag 1232896)

Ob man sie öffnen kann oder nicht, hängt nur davon ab:

1. Ist der Pfad und Dateiname korrekt
2. Habe ich / der Prozess das Recht die Datei / den Pfad zu öffnen / zu lesen

Einspruch, das ist nicht ganz richtig, wenn eine Datei auf "Readonly" steht kann es durchaus Fehlermeldungen geben (filemode);

Zitat:

Zitat von ChrisE (Beitrag 1232896)

Ich glaube es wäre an der Zeit zu zeigen:

• wie du die Datei öffnest
• woher die Informationen zum Dateinamen inkl. Pfad kommen
• welche Rechte auf der eigentlichen Zieldatei eingetragen sind

Dem wäre eigentlich nur noch die konkrete Fehlermeldung hinzuzufügen.

Gruß
K-H

[ZOD]

@p80286
ich will wirklich nicht ungeduldig klingen, aber ich hatte
die Hoffnung, daß meine bisherigen Posts - vor allem der letzte -

Zitat:

Zitat von ZOD (Beitrag 1232909)

@Chris
Kurzantwort
Der Zugriff auf die Dateien erfolgt mit ShellExecute, die Pfadnamen sind
in einer DB gespeichert mit "hart" vorgegebenen LW-Buchstaben.

Langantwort:
Öffne ich aus dem Programm heraus das Verzeichnis einer der ""Problem-Dateien" mit

Delphi-Quellcode:

ShellExecute(Application.Handle, 'explore', PChar(Directoryname), nil, nil, SW_SHOWNORMAL);

so bekomme ich als Rückgabewert
"5" - also
"Fehler beim gemeinsamen Zugriff auf eine Datei im Netz oder Fehler beim Zugriff auf eine gesperrte Datei im Netz."

Wenn ich dann aus genau dem jetzt laufenden Programm heraus einen Explorer für das EXE-Verzeichnis starte mit

Delphi-Quellcode:

ShowDirectory(ExtractFilePath(Application.ExeName))

Dann kann ich mich darin bis zum ursprünglichen Verzeicnis durchklickern
und bekomme hier auch alle Dateien angezeigt und kann diese per Doppelkklick öffnen.

Die Pfade sind wie geschildert "hart" in einer DB gespeichert, incl. Laufwerksbuchstaben.
(Wir verwenden für einige Server Volumes fest vergebene LW-Buchstaben).

Die Rechte auf die Zieldatei sind da - sonst könnte ich sie ja nicht wie
oben geschildert im aus dem Programm heraus gestarteten Explorer anzeigen.

Für die Anzeige wird ein normales ShellExecute verwendet, zuerst wird
das Programm für die Anzeige über die FileExtension ermittelt und dieses
dann ebenfalls per ShellExecute aufgerufen. Klappt hervorragend bei OS <= XP.

Ich verstehe einfach nicht, warum der Benutzer einmal die Rechte hat und
ein andermal die Rechte nicht hat.

diese Fragen beantwortet.

Naja - ich bin sicher auch etwas genervt, da ich hier nicht vorwärts komme,
oder mich zu blöde anstelle.

Einmal andersherum gefragt:
wie starte ich einen Prozess (z.B. über CreateProcessAsUser) für den aktuell
am OS angemeldeten Benutzer (NICHT den Benutzer meiner Startroutine wg. Admin-Recht
) ohne daß der Benutzer jedesmal sein PW neu eintippen muß?

Gefunden habe ich bisher

http://www.delphipraxis.net/884994-post13.html

hier geht es aber um Registry-Einträge.

[musicman56]

Hallo nochmal,

hast du es wirklich schon mit ShellExecuteEx als Administrator versucht?

Delphi-Quellcode:

function ShellExec(aHandle: HWND; FileName, Parameters, Directory: string;
                   ShowCmd: Integer; AsAdmin, Wait: boolean): Boolean;
var
  SEI: TShellExecuteInfo;
begin
  FillChar(SEI, SizeOf(SEI), #0);
  SEI.cbSize := SizeOf(SEI);
  SEI.Wnd := aHandle;
  SEI.fMask := SEE_MASK_NOCLOSEPROCESS;
  if AsAdmin then SEI.lpVerb := 'runas'
  else SEI.lpVerb := 'open';
  SEI.lpFile := PChar(FileName);
  SEI.lpParameters := PChar(Parameters);
  SEI.lpDirectory := PChar(Directory);
  SEI.nShow := ShowCmd;
  Result := ShellExecuteEx(@SEI);
  if Result then
  if Wait then begin
    if SEI.hProcess > 32 then begin
      WaitForInputIdle(SEI.hProcess, INFINITE);
      WaitForSingleObject(SEI.hProcess, INFINITE);
    end;
  end;
  CloseHandle(SEI.hProcess);
end;

[jaenicke]

Und noch einmal:
Es geht darum aus einem Adminprozess einen Prozess im Usermode zu starten, nicht umgekehrt. Adminrechte hat er dank Manifest schon.

[musicman56]

Zitat:

Zitat von ZOD (Beitrag 1232909)

Ich verstehe einfach nicht, warum der Benutzer einmal die Rechte hat und ein andermal die Rechte nicht hat.

Aus diesem Grund ist ja mein Grundgedanke, wenn der erste Prozess als Admin (mit ShellExecuteEx) gestartet wird, und die Adminrechte an die von diesem Prozess ebenfalls mit ShellExecuteEx gestarteten Prozesse weitergereicht werden, dann müsste es doch gehen. Aber vielleicht täusche ich mich ja auch, und darum halte ich mich jetzt besser raus.

[jaenicke]

Zitat:

Zitat von musicman56 (Beitrag 1232953)

Aus diesem Grund ist ja mein Grundgedanke, wenn der erste Prozess als Admin (mit ShellExecuteEx) gestartet wird, und die Adminrechte an die von diesem Prozess ebenfalls mit ShellExecuteEx gestarteten Prozesse weitergereicht werden, dann müsste es doch gehen.

Der Adminprozess hat die Zugriffsmöglichkeit aber gerade nicht, nur der normale Benutzer. Deshalb ist das was du beschreibst das Problem und nicht die Lösung.

[ZOD]

Guten Morgen zusammen,

meine Suche im allwissenden Netz war bisher recht erfloglos.

Zum Thema "run as administrator" or "elevated" gibt es viel.

Dazu, wie ein Prozess aus einem "elevated" gestarteten Prozess im
Kontext des angemeldeten Users heraus gestartet werden kann,
finde ich nichts.

Neue Idee:
die Startroutine erzeugt einen Eintrag im Task Scheduler, der
das eigentliche Programm startet (ja - ist mit der Speerspitze durch die Brust ins Auge gezielt).
Hat mir dazu jemand einen Tip, wie ich das machen könnte?

Danke.

[jaenicke]

Ich habe keine Zeit, habe aber mal ganz kurz geschaut, ins Auge gesprungen sind mir diese Funktionen:
CreateRestrictedToken
CreateProcessWithToken
Ob es das ist, kann ich jetzt nicht schauen.

[ZOD]

Guten Morgen,

nach einigem Herumprobieren und Suchen bin ich auf

http://stackoverflow.com/questions/1...785337#2785337


gestoßen und kann nun endlich auch unter Win7 mit folgendem Code
mein Programm aus der Startroutine heraus so starten, daß die Dateizugriffe keine
Fehler mehr ergeben:

Delphi-Quellcode:

      tmpS := IncludeTrailingPathDelimiter(GetEnvironmentVariable('WINDIR')) + 'explorer.exe';
      tmpS1 := '"' + Trim(ProgDateiPfad) + Trim(' ' + Trim(ProgParameter)) + '"';
      tmpExitCode :=
        ShellExecute(
         GetDesktopWindow,
         'open',
         PChar(tmpS),
         PChar(tmpS1),
         nil,
         SW_SHOWNORMAL);
      tmpLastOSError := GetLastError;
      result := tmpLastOSError <> 0;

Nun habe ich (natürlich) ein neues Problem:
bei jedem Aufruf kommt die Sicherheitswarnung

Dateidownload - Sicherheitswarnung
Möchten Sie diese Datei speichern oder ausführen?

Und nach Klick auf <Ausführen> natürlich noch

Windows Explorer - Sicherheitswarnung
Der Herausgeber konnte nicht verifiziert werden.
Möchten Sie diese Software ausführen.

Hat jemand eine Idee, wie ich ohne Verstellen der Sicherheitsstufe
an jeder Workstation diese Meldungen loswerde?

Danke.

[jaenicke]

Ohne das richtig zu machen, wirst du die Meldung mit dem Speichern natürlich nicht los.

Die Sicherheitswarnung kannst du nur beheben indem du deine Software mit einem Zertifikat versiehst. Denn die Warnung sagt ja genau aus, dass der Herausgeber nicht verifiziert werden kann. Und das kann Windows nur über ein gültiges Zertifikat.

Aber trotzdem ist deine "Lösung" von hinten durch beide Ohrläppchen in den Zeh geschossen...

Ich habe einmal zu den Funktionen aus meinen Links noch einmal kurz Google bemüht... Hier findest du eine fertige Lösung in C++, die exakt für den Zweck ist:
http://www.codeproject.com/Tips/2309...ss-with-Medium

[markus5766h]

Zitat:

Zitat von jaenicke (Beitrag 1232694)

Wenn das Delphi 7 bereits unterstützt, kannst du in den Debugger-Optionen die Option "Debug in Spawned-Prozessen" aktivieren,
um nach dem Start der Exe weiter zu debuggen.

. . . wird von Delphi 7 unterstützt.