Autor |
Beitrag |
Steve1024
      
Beiträge: 141
Windows 2K, XP, 7 & Server 2003 - 2008; Linux (Ubuntu, Fedora)
D7, D05, D06, D09, DXE
|
Verfasst: Di 25.12.07 21:04
Hi,
wisst ihr, ob es möglich ist einen Thread unter anderen Benutzerinformationen auszuführen? Eigentlich sollte das doch möglich sein, oder? Ich denke Windows arbeitet mit den Diensten doch auch so, oder?
Ich danke euch für eure Hilfe.
mfg
Steve
|
|
Xentar
      
Beiträge: 2077
Erhaltene Danke: 2
Win XP
Delphi 5 Ent., Delphi 2007 Prof
|
Verfasst: Di 25.12.07 21:21
Ich denke nicht, dass das geht.
Höchstens die ganze Anwendung.
Die läuft halt unter dem Benutzer, der sie gestartet hat. Und wenn es sich um einen Dienst handelt, läuft die anwendung halt als "System".
Aber wofür braucht man sowas?
|
|
Narses
      

Beiträge: 10183
Erhaltene Danke: 1256
W10ent
TP3 .. D7pro .. D10.2CE
|
Verfasst: Di 25.12.07 21:32
Moin!
Steve1024 hat folgendes geschrieben: | wisst ihr, ob es möglich ist einen Thread unter anderen Benutzerinformationen auszuführen? Eigentlich sollte das doch möglich sein, oder? |
Nein, AFAIK geht das nicht über die Win-API. Aber schau doch mal selbst:
msdn2.microsoft.com/...ms684847(VS.85).aspx
Steve1024 hat folgendes geschrieben: | Ich denke Windows arbeitet mit den Diensten doch auch so, oder? |
AFAIK ist ein Dienst ein Prozess, und diese kann man unter einer andern Anmeldung starten.
cu
Narses
_________________ There are 10 types of people - those who understand binary and those who don´t.
|
|
Steve1024 
      
Beiträge: 141
Windows 2K, XP, 7 & Server 2003 - 2008; Linux (Ubuntu, Fedora)
D7, D05, D06, D09, DXE
|
Verfasst: So 30.12.07 16:52
Aber es gibt doch auch DLL-Dateien, welche Dienste beinhalten. Wie wird das da denn dann gemacht??
|
|
Reinhard Kern
      
Beiträge: 591
Erhaltene Danke: 14
|
Verfasst: Mo 31.12.07 03:24
Steve1024 hat folgendes geschrieben: | Aber es gibt doch auch DLL-Dateien, welche Dienste beinhalten. Wie wird das da denn dann gemacht?? |
Siehe Computerverwaltung -> Dienste: für jeden Dienst ist anzugeben, unter welchem Konto er gestartet werden soll ("Anmelden als"). Viele Dienste laufen unter dem lokalen Systemkonto, aber ACHTUNG damit hat der Dienst keinen Zugriff u.a. auf Netzwerkresourcen. Einen realen Benutzer zu nehmen ist eher eine schlechte Idee, besser ist es für Client-Server-Systeme, einen speziellen User einzurichten, z.B. FAX_CLIENT für die Client-Software eines Faxsystems, und dem die notwendigen Rechte im System zu geben.
Zur ursprünglichen Frage: ich widerspreche den bisherigen Antworten. Jede Funktion und jeder Thread kann unter einem anderen User-Account arbeiten, dazu dient unter Windows die Funktionalität "Impersonation". Das läuft darauf hinaus, per Funktionsaufruf auf einen anderen Account umzuschalten und auch wieder zurück.
Gruss Reinhard
|
|
Bernhard Geyer
      
Beiträge: 721
Erhaltene Danke: 3
|
Verfasst: Mo 31.12.07 10:19
Reinhard Kern hat folgendes geschrieben: | Jede Funktion und jeder Thread kann unter einem anderen User-Account arbeiten, dazu dient unter Windows die Funktionalität "Impersonation". Das läuft darauf hinaus, per Funktionsaufruf auf einen anderen Account umzuschalten und auch wieder zurück. |
Ich würde fast darauf Tippen das diese unter Vista mit aktiven UAC (User Account Control) nicht mehr gehen wird sich hier für eine Funktion Admin-Rechte zu holen.
|
|
Motzi
      
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 31.12.07 13:53
Das wichtigste hat Reinhard bereits geschrieben, ich schieb nur mehr die entsprechenden APIs hinterher: IMPERSONATELOGGEDONUSER, IMPERSONATESELF, REVERTTOSELF
Ich bin mir nicht sicher inwieweit die UAC unter Vista hierbei mitspielt (das SDK schweigt sich darüber aus), aber ansich denke ich nicht, dass es größere Probleme gibt. Schlimmstenfalls kommt vermutlich eine Abfrage ob der Prozess diese Aktion durchführen darf oder nicht.
Gruß, Motzi
_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
Bernhard Geyer
      
Beiträge: 721
Erhaltene Danke: 3
|
Verfasst: Di 01.01.08 16:35
Motzi hat folgendes geschrieben: | Schlimmstenfalls kommt vermutlich eine Abfrage ob der Prozess diese Aktion durchführen darf oder nicht. |
AFAIK ist genau das mit UAC nicht möglich. Entweder hat der Prozess Admin-Recht (beim start mit Dialog abgefragt) oder nicht. Solche hochgestuften Threads bergen imm die Gefahr das von nicht-Priviligierten Thread durgegriffen wird da zwischen Threads kein Speicherschutz besteht.
|
|
NeoInDerMATRIX
      
Beiträge: 245
Win95, Win98(+se), WinNT, Win2000, WinME, WinXP(+pro), VISTA, Linux(SuSe), DOS [MultiMon(3)], Vista
D6 PeE + (FP 2.0l) + D3 Pe + D2005+ D2006 Arch
|
Verfasst: So 20.01.08 17:43
Das stimmt soch auch nicht, denn unter Vista ist es Möglich ein Programm als User zu starten und wenn dieses dann auf einen Admin Funktion der API zugreift kommt diese leicht nervige Frage ob das erlaubt werden soll oder nicht. (ERFAHRUNG)
Mfg
neo
|
|
Bernhard Geyer
      
Beiträge: 721
Erhaltene Danke: 3
|
Verfasst: So 20.01.08 22:24
NeoInDerMATRIX hat folgendes geschrieben: | Das stimmt soch auch nicht, denn unter Vista ist es Möglich ein Programm als User zu starten und wenn dieses dann auf einen Admin Funktion der API zugreift kommt diese leicht nervige Frage ob das erlaubt werden soll oder nicht. (ERFAHRUNG) |
Bist du dir sicher das hier nicht einfach eine 2te Exe (oder ein COM-OutofProcess-Server) gestartet wird?
|
|
Dezipaitor
      
Beiträge: 220
|
Verfasst: So 20.01.08 23:54
Also ersteinmal: Man kann einzelne Threads unter einem anderen Benutzer ausführen. Das geht zu fast beliebigen Zeitpunkten, und man kann es hin und herschalten.
Ein Token ist ein Benuterausweiß, der die Sicherheitseinstellungen für einen Benutzer enthält. Jeder Prozess erhält ein solches Token von dem Prozess, das ihn gestartet hat. Jeder Thread fährt normalerweise zuerst mit diesem Prozesstoken. Jedoch ist es möglich einen Thread mit einem eigenen Token zu besetzen und dieses beliebig zurückzusetzen. Wenn kein Threadtoken aktiv ist, so wirkt das Prozesstoken. Im Gegensatz zum Threadtoken, kann man Prozesstoken nicht auswechseln. Um ein Token zu setzen kann man SetThreadToken oder eines der ImpersonateXXXX WinAPI Funktionen verwenden.
Die UAC wirkt bei solchen Personifizierungen (Impersonation) nicht mit, da unter Vista ein Token keine Adminrechte enthält.
Unter Vista hat ein Token einen Zwilling, sobald es die Gruppe Administratoren enthält. In diesem Fall erstellt Vista ein Zwillingstoken, welches die Gruppe Administratoren nur für Verweigerungen enthält. Das Twintoken kann man mit GetTokenInformation erhalten. Ein Administrator fährt daher zuersteinmal immer nur dem Token, welches die verweigernden Admingruppe enthält. Das andere Token kann man nicht mit SetThreadToken auf einen Thread setzen, da dies ja eine Lücke wäre. Dies könnte nur ein Administrator oder Dienst.
Um Code mit diesem Admin-Token auszuführen muss man einen neuen Prozess starten. Dies geht unter Vista mit einem COM Moniker, welches einen Prozess mit den erweiterten Rechten startet. Eine andere Möglichkeit zum Manifest gibt es nicht.
Es ist übrigens nicht möglich mit LogonUser ein Admintoken zu bekommen.
Dieses Beispiel in JWSCL zeigt eine Personifikation.
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85:
| program Impersonation;
uses {$IFDEF FPC} interfaces, Forms, {$ENDIF} SysUtils, jwaWindows,
JwsclToken, JwsclTypes, JwsclCredentials, JwsclStrings;
procedure ShowUserName(Caption : String); var pLoggedOnUserName : array[0..255] of char; iSize : Cardinal; str : String; begin FillChar(pLoggedOnUserName,sizeof(pLoggedOnUserName),0); iSize := sizeof(pLoggedOnUserName); GetUserName(@pLoggedOnUserName, iSize); str := 'GetUserName: Your username is : ' + String(pLoggedOnUserName); MessageBox(0,PChar(str),PChar(Caption),MB_OK); end;
var Token : TJwSecurityToken; Prompt : TJwCredentialsPrompt; sUser, sDomain, sPass : TJwString;
begin {$IFDEF FPC} Application.Initialize; {$ENDIF} Token := TJwSecurityToken.CreateTokenEffective(TOKEN_ALL_ACCESS);
Prompt := TJwCredentialsPrompt.Create; Prompt.UserName := 'Administrator'; Prompt.Password := '123'; Prompt.Caption := 'Impersonation demonstration'; Prompt.MessageText := 'Enter a account name and passwort to impersonate that user.'; Prompt.Flags := [cfFlagsDoNotPersist];
try
if not Prompt.ShowModal(false) then exit;
TJwCredentialsTools.ParseUserName(Prompt.UserName, sUser, sDomain); except FreeAndNil(Prompt); FreeAndNil(Token);
raise; end;
try Token := TJwSecurityToken.CreateLogonUser(sUser, sDomain, Prompt.Password, LOGON32_LOGON_INTERACTIVE,0); except raise; end;
ShowUserName('Before impersonation');
Token.ImpersonateLoggedOnUser; ShowUserName('After impersonation');
Token.RevertToSelf;
ShowUserName('Revert to self ');
Token.Free;
end. |
|
|
Steve1024 
      
Beiträge: 141
Windows 2K, XP, 7 & Server 2003 - 2008; Linux (Ubuntu, Fedora)
D7, D05, D06, D09, DXE
|
Verfasst: So 27.01.08 16:43
Das freut mich, dass es doch scheinbar möglich ist.
Jetzt frage ich mich leider nur noch wie... mit dem API Funktionen komm ich ned ganz klar...
Meine Idee wäre folgende:
LogonUser und mit dem Ergbnis dann das ThreadAttributes füllen und den Tread erstllen bzw. starten. Dabei habe ich aber jetzt noch keine Ahnung, wie ich denn die ThreadAttributes voll bekomme?! Woher bekomme ich die benötigten infos?!
Gibt es auch ein LogonUser, wo ich ein solches record zurück bekomme???
Vielen dank für eure Hilfe 
|
|
|