fehlende Rechte nach EXE start auf WIN7

[jaenicke]

Zitat von ZOD:

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

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 von ZOD:

...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 von ZOD:

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


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

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 von jaenicke:

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?