User-Spezifische Folder ermitteln wenn mit "Run als Administrator" gestartet wurde

[Luckie]

Zitat von Christoph Schneider:

Um beispielsweise ein Menu-Eintrag ins Startmenu zu schreiben ist der Zeitpunkt der Installation sicher der einzig richtige.

Und was ist mit den anderen Benutzern? Wenn du keine halben Sachen machen willst, müsstest du alle Benutzer durchgehen und für jeden Benutzer den Startmenüeintrag anlegen.

[himitsu]

Zitat von Luckie:

Wenn du keine halben Sachen machen willst, müsstest du alle Benutzer durchgehen und für jeden Benutzer den Startmenüeintrag anlegen.

Für sowas gibt es aber den Default-User.

Ich fände es schön, wenn setups fragen würden (was einige Wenige sogar schon machen) wo es installiert werden soll.
- für aktuellen benutzer
- für alle Benutzer

[Luckie]

Dann muss er aber nicht umständlich mit Tokens und Sessions rumhantieren. Den Default-User gibt es nicht, das ist nur ein Ordner unter den Benutzerprofilen, der für alle gilt. Da kann er dann einfach seinen Startmenüeintrag machen. Was ich aber auch nicht leiden kann, weil eine Verknüpfung die da liegt, kann der einzelne Benutzer nicht löschen oder verschieben, wenn er sie nicht haben will oder an einer anderen Stelle.

[Christoph Schneider]

Genau, mein Installationsprogram frägt den Anwender, ob für alle oder nur für den laufenden User installiert werden soll. Im ersten Falle wird dann als CSIDL bspw. für den Startordner CSIDL_COMMON_PROGRAMS verwendet während für den aktuellen User CSIDL_PROGRAMS abgefragt wird. Dieser Ansatz funktionierte auch bis und mit XP problemlos. Seit aber immer mehr User ohne Admin-Rechte laufen und gezielt für die Installation ein User-Wechsel vorgenommen wird, läuft dies wie erwähnt nicht mehr.
Die Verwendung des Default-Users ist mea. auch nicht geeignet, den dieser wird als Template-User verwendet, wenn in Zukunkt ein neuer User eingerichtet wird.

[himitsu]

Stimmt, DefaultUser war eh falsch ... gab es nicht früher mal einen User AllUsers?

In Win2008 isses C:\ProgramData\Microsoft\Windows\Start Menu\Programs .


Tja, dann wirst du es wohl doch z.B. mal über den Besitzer der Session probieren müssen.

[Christoph Schneider]

Unterdessen habe ich meinen Fehler entdeckt. Es lag an einem Seiteneffekt und gar nicht am gezeigten Code - der funktionierte bereits richtig.
Ich habe für Test-Zwecke das Token noch gebraucht um Domain und UserName darzustellen. Dafür hätte ich aber das
Token vorher noch duplizieren müssen. Hier zeige ich gerne die jetzt implementierte Lösung:

Code:

function CreateTokenOfProcess(ProcessId: DWORD): THandle;
const
  PROCESS_QUERY_LIMITED_INFORMATION = $1000;
var
  ProcessHandle, TokenHandle: THandle;
begin
  result := 0;
  ProcessHandle := 0;
  try
    ProcessHandle:= OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, True, ProcessId);
    if ProcessHandle <> 0 then
    begin
      if OpenProcessToken(ProcessHandle, TOKEN_QUERY or TOKEN_IMPERSONATE, TokenHandle) then
        result := TokenHandle;
      // Call CloseHandle(TokenHandle) by caller
    end;
  finally
    CloseHandle(ProcessHandle);
  end;
end;

function GetParentProcessID: DWORD;
// This function should be part of the API!
var
  Snap: THandle;
  Proc: TProcessEntry32;
  CurrentProc: cardinal;
begin
  result := 0;
  Snap := CreateToolHelp32SnapShot(TH32CS_SNAPALL, 0);
  try
    CurrentProc := GetCurrentProcessId;
    Proc.dwSize := SizeOf(TProcessEntry32);
    Process32First(Snap, Proc);
    repeat
      if Proc.th32ProcessID = CurrentProc then
      begin
        result := Proc.th32ParentProcessID;
        Break;
      end;
    until (not Process32Next(Snap, Proc));
  finally
    CloseHandle(Snap);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  hres: HResult;
  Folder: array[0..Max_Path] of Char;
  Token: THandle;
begin
  Token := CreateTokenOfProcess(GetParentProcessID);
  try
    hRes := SHGetFolderPath(Handle, CSIDL_PROGRAMS, Token, SHGFP_TYPE_DEFAULT, Folder);
    if not Succeeded(hRes) then
      raise Exception.Create(SysErrorMessage(hRes)));
    ShowMessage('SHGetFolderPath Succeeded:' + string(Folder));
  finally
    CloseHandle(Token);
  end;
end;

Den Ansatz über die Session ID bringe ich leider nicht zum Laufen. Hier kurz der Abriss:

Code:

function WTSQueryUserToken(SessionId: DWORD; phToken: pHandle):bool; stdcall; external 'wtsapi32.dll';
function ProcessIdToSessionId(dwProcessId: DWORD; pSessionId: DWORD): bool; stdcall; external 'Kernel32.dll';

function CreateTokenFromSession: THandle;
var
  SessionID: cardinal; 
begin
  if not ProcessIdToSessionId(GetCurrentProcessId, DWORD(@SessionID)) then
    raise Exception.Create(SysErrorMessage(GetLastError)));
  { Korrekte Session ID erhalten }
  if not WTSQueryUserToken(SessionId, @result) then
    raise Exception.Create(SysErrorMessage(GetLastError)));
    { Hier bekomme ich immer "A required privilege is not held by the client" }
end;

Ich versuchte noch das Privileg SE_TCB_NAME zu setzen, scheiterte aber auch damit.

Die Lösung mit dem Parent-Prozess sollten im normalen Umfeld eigentlich gut funktieren. Probleme entstehen,
wenn der Installer aus einem Batch oder einer anderen Applikation gestartet wird, die bereits den User-Switch
vorgenommen haben. Da mein Installer über kein Command-Line Interface verfügt, mache ich mir hierzu aber
keine weiteren Sorgen.
Im Gegensatz zu Unix fehlt unter Windows ein richtiger Root-Process, der die User-Session gestartet hat. Der
Explorer-Prozess übernimmt zwar mehrheitlich diese Aufgabe, kann aber jederzeit beendet und neugestartet werden.
Ergo ist es schwierig über den Prozessbaum den gültigen Root-Prozess zu finden. Aus diesem Grunde versuche ich
mal mit diesem Workaround zu leben.

[Luckie]

OK, das ist jetzt für Alice die den Installationsprozess angestoßen hat. Und was ist mit Benutzer Bob, der sich am nächsten Tag anmeldet und die Software nutzen will?