ImpersonateLoggedOnUser - wann darf RevertToSelf aufgerufen werden?

hustbaer

Wenn ich mir mit LogonUser ein token hole, und dieses mit ImpersonateLoggedOnUser "aktiviere" um auf Files zuzugreifen, wie lange muss ich das dann so lassen (also wie lange darf ich dann nicht RevertToSelf aufrufen)?
Reicht es wenn man das File mit CreateFile aufmacht und dann gleich RevertToSelf aufruft, oder muss das Token aktiv bleiben während man z.B. in dem File liest und/oder schreibt?

Selbe Frage für SQL Server Connections - muss das Token aktiv bleiben während die Connection verwendet wird, oder reicht es wenn das Token bei der Herstellung der Connection aktiv ist?

Noch eine Frage: gibt es irgendwelche Systemfunktionen die RevertToSelf aufrufen, bzw. sonstige Funktionen wo das passieren könnte (MFC/ATL/...)?

Und zum Schluss: kann man das default Token eines Prozesses nachträglich ändern?

Martin Richter

hustbaer schrieb:

Wenn ich mir mit LogonUser ein token hole, und dieses mit ImpersonateLoggedOnUser "aktiviere" um auf Files zuzugreifen, wie lange muss ich das dann so lassen (also wie lange darf ich dann nicht RevertToSelf aufrufen)?
Reicht es wenn man das File mit CreateFile aufmacht und dann gleich RevertToSelf aufruft, oder muss das Token aktiv bleiben während man z.B. in dem File liest und/oder schreibt?

IMHO wird das nur notwendig bis das Handle existiert. Theoretisch kannst Du solch ein Handle ja an andere Prozesse weitereichen. Das würde ja sonst nichtgehen.

hustbaer schrieb:

Selbe Frage für SQL Server Connections - muss das Token aktiv bleiben während die Connection verwendet wird, oder reicht es wenn das Token bei der Herstellung der Connection aktiv ist?

Native oder ADO OLE/DB? Aber es müsste hier genauso sein. Solange Du eben nicht in die Versuchung kommst die Verbindung neu aufzubauen.

hustbaer schrieb:

Noch eine Frage: gibt es irgendwelche Systemfunktionen die RevertToSelf aufrufen, bzw. sonstige Funktionen wo das passieren könnte (MFC/ATL/...)?

Ich kenne keine normale ATL/MFC Funktion die RevertToSelf ausführt.
In der ATL wird evtl. im Init Code CAtlAllocator::Init RevertToSelf druchgeführt. Das ganze wird für die ATL/MFC TRace Funktionen und das Vererben der Trace Flags verwendet.

IMHO ist das aber auch die einzige Stelle...

hustbaer schrieb:

Und zum Schluss: kann man das default Token eines Prozesses nachträglich ändern?

Nope! Dann wäre UAC unter Vista ja ein Kinderspiel...

hustbaer

Erstmal danke für die Info.
Vonwegen SQL Server, da gehts um ADODB.

Und ich hätte gleich noch ein paar Fragen zu dem Thema... :

Wenn ich mehrmals hintereinander ImpersonateLoggedOnUser mit dem selben Handle aufrufe, das müsste egal sein, oder? Bzw. wenn ich z.B. "impersonate(a), impersonate(b), impersonate(a), revert()" macht, das müsste auch gehen, richtig?
Hält ImpersonateLoggedOnUser das Handle offen, oder passieren da schlimme Dinge wenn ich "impersonate(a), close(a)" mache?
Ich hatte vor längerer Zeit mal was mit LogonUser & ImpersonateLoggedOnUser gemacht, und das hat gut funktioniert wenn ich den Prozess als Admin so gestartet habe (Explorer Doppelklick halt), allerdings nichtmehr funktioniert sobald ich den als "scheduled task" laufen lassen hab. Leider weiss ich nichtmehr unter welchem User ich diesen Task laufen lassen hab, kann leicht sein dass es an den etwas seltsamen Eigenheiten der "scheduled tasks" gelegen hat (die irgendwie garnicht so tun wie man will wenn man nicht den "LOCAL SYSTEM" Account verwendet, was ich damals aber nicht wusste). Kann auch sein dass ich als Userkonto kein Adminkonto angegeben hatte, und da das Windows 2000 war ... fehlte da wohl das SE_TCB_NAME Privileg. Könnte aber auch ein anderes Problem gewesen sein.
Kurz: weisst du irgendwas worauf man da aufpassen muss wenn das als "scheduled task" bzw. auch als Service laufen soll? Dort wo ich es als "scheduled task" laufen lasse werde ich diesmal auf jeden Fall das "LOCAL SYSTEM" Konto verwenden, sonst funktioniert das so und so nicht gescheit
Hast du eine Ahnung was passiert wenn ich erst mit LogonUser(...LOGON32_LOGON_NEW_CREDENTIALS...) auf eine SMB-Share zugreife, und dann später ein Laufwerk auf die gleiche Share aber mit anderen Credentials mappen will? Mehrere Zugriffe mit LOGON32_LOGON_NEW_CREDENTIALS und unterschiedlichen Credentials gehen ja *angeblich*, aber was passiert wenn noch keine Verbindung zu dem entsprechenden Server besteht und ein Zugriff über LOGON32_LOGON_NEW_CREDENTIALS gemacht wird?