In Deutschland läuft man Gefahr, verhaftet zu werden, wenn man mit einem zweiten Ausweis mit anderen persönlichen Daten herumläuft... In Windows Vista hat aber jeder Administrator einen zweiten Token in der Tasche - und da ist das ganz normal. Zwei Token - einen nicht angehobenen Token mit wenig Rechten und einen angehobenen Token mit mehr Rechten. Hat man das UAC Popup bestätigt, arbeitet man mit dem angehobenen Token, ansonsten mit dem nicht angehobenen Token. Einer ist also immer aktiv, der andere ist im Hintergrund.
Aber was heißt "Hintergrund"? Im "Hintergrund" heißt, dass im aktiven Token ein Handle auf den Token vorhanden ist, der sich im Hintergrund befindet.
Dieses Handle kann man über die API GetTokenInformation mit der TOKEN_INFORMATION_CLASS (zweiter Parameter der Funktion) TOKEN_LINKED_TOKEN (19) erlangen. Um das Handle verwenden zu können, muss man es sich nur noch in den eigenen Prozess holen, wenn man von einem anderen Prozess aus arbeitet.
Das ganze ist eine sehr nette Geschichte, mit der man schöne Sachen anfangen kann - besonders wenn das eigene Programm (eventuell als Service) mit einem Systemtoken arbeitet.
"Screenshot" vom Token unter Vista - wie sieht der aus?
-
-
-
Aber nur Vista, richtig?
-
Zitat von Frabbing;683422
Aber nur Vista, richtig?
Ja, nur Vista. Das ganze nennt sich UAC. -
-
Zitat von p. specht;683557
Ahhhhh.... Benutzerkontensteuerung ? Wikipedia
Ja, hier ging es ja auch um MIC, den zweiten neuen Bereich. -
Nochmal kleine Zusammenfassung, um das Durcheinander etwas zu ordnen - auf was sollte man also achten?
a) Programme, die in Registry unter HKEY_LOCAL_MACHINE schreiben (oder auch von dort wichtige Werte lesen müssen), sollten sich Adminrechte verschaffen, da sonst in einen falschen Schlüssel geschrieben (bzw. unter Umständen auch aus ihm gelesen) wird.
b) Programme, die Prozessdaten auslesen wollen, sollten sich selbst das SeDebugPrivilege aktivieren, da sonst aufgrund der neu eingeführten MIC kein Zugriff auf Prozesse mit höherem Integritätslevel besteht.
c) Programme, die administrative Aufgaben erledigen müssen, sollten sich Adminrechte über das Manifest oder die API ShellExecute (Profan Shellexec) anmelden, da ansonsten die Gruppe Administratoren im Token deaktiviert ist und wichtige Privilegien fehlen (zum Beispiel Setzen der Zeit).
d) Ein unter Vista gestartetes Programm, dass sich keine Adminrechte angemeldet hat, kann nicht an allen Orten Dateien und Ordner erstellen oder diese bearbeiten.
e) Services laufen unter Vista in einer eigenen Session. Um interaktive Prozesse im System-Account auf dem Desktop des eingeloggten Users zu starten, reicht es deshalb nicht mehr aus, ein normales Programm über einen interaktiven Service ausführen zu lassen. Das so gestartete Programm würde dann auf dem falschen Desktop erscheinen.
Achtung, Zusatz: Wenn ein Programm das mit Adminrechten gestartet wurde, eine Datei bearbeitet, die einen "symbolisch verlinkten" Pfadnamen besitzt (zum Beispiel C:\Programme...), kann es dazu kommen, das nicht die selbe Datei bearbeitet wird, wenn das Programm ohne Adminrechte gestartet wird!!! Gründe dafür dürften in Punkt a) und d) liegen.
Beispiel: Startet man Profaneditor mit Adminrechten und editiert eine im Ordnner Includes liegende INC, stehen diese Änderungen dem Editor nicht mehr zur Verfügung, wenn es ohne Adminrechte gestartet wird. Beim Compilieren werden dann andere Includes verwendet - böse Falle!
Was bedeutet das für eigene Programme, die Daten auf der Festplatte speichern sollen und sowohl mit, als auch ohne Adminrechte laufen sollen? Man muss sich sehr genau überlegen, wo man die zu speichernden Daten genau auf der Festplatte ablegt. -
Böse Falle. Also warte ich noch mit einem Update des Betriebssystems.
-
Zitat
Also warte ich noch mit einem Update des Betriebssystems
Genau - nach dem, was man so hört und gehört hat, ist VISTA "ein Schuss in den Ofen" und Window-7 wird vielleicht besser werden
-
Zitat von Frabbing;685100
Böse Falle. Also warte ich noch mit einem Update des Betriebssystems.
Ich denke mal, daran wird sich auch unter Windows7 nichts ändern, da das ein "Sicherheitsfeature" ist.
Zitat von horsthorn;685107Genau - nach dem, was man so hört und gehört hat, ist VISTA "ein Schuss in den Ofen" und Window-7 wird vielleicht besser werden
Vista ist in Bezug auf die Verschleuderung von Systemresourcen die letzte Krücke. An den Sachen, die ich hier beschrieben habe, wird sich aber wohl auch in Windows7 nichts ändern. -
Zitat
Vista ist in Bezug auf die Verschleuderung von Systemresourcen die letzte Krücke.
Hat man ja allen Windows davor auch nachgesagt.
-
Zitat von horsthorn;685107
Genau - nach dem, was man so hört und gehört hat, ist VISTA "ein Schuss in den Ofen" und Window-7 wird vielleicht besser werden
Das kann ich so nicht bestätigen.
Ich habe keinerlei Probleme mit Vista.
Windows7 wiederum gefällt mir gar nicht, weder vom Aussehen, und schon gar nicht von der Bedienung.Wie Andreas schon schrieb "Man muss sich sehr genau überlegen, wo man die zu speichernden Daten genau auf der Festplatte ablegt."
Man kann seine Programme so ausstatten, dass sie normal laufen, oder normal ohne virtualisierung oder mit Adminrechten. Je nachdem was eben machen will mit seinem Programm.
Für normale Programme empfiehlt sich der Modus ohne Virtualisierung (User-Modus). Für Programm, die Adminrechte benötigen ( Setups z.B ), gibt man eben die Aufforderung Adminrechte zu holen mit.Jetzt fehlt nur noch die Erklärung wie man das machen kann.
Über ein Manifest in den Resourcen von der Prfrun32.exe. Für den XP-Style ist ja schon ein Manifest eingebaut.
Wenn man das so lässt wie es ist, wird das Programm mit Virtualisierung laufen.Mir dem Resource-Hacker oder anderen Resourcen-Tools kann das Manifest in der Prfrun32.exe geändert werden.
Hier ein Manifest, dass das Programm ohne Virtualisierung (User-Modus) mit XP-Style laufen lässt.
XML
Alles anzeigen<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="CompanyName.ProductName.YourApp" type="win32" /> <description></description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
Und ein Manifest, dass Adminrechte für das Programm anfordert, mit XP-Style.
XML
Alles anzeigen<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="CompanyName.ProductName.YourApp" type="win32" /> <description></description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
-
8O:stein::morse:
-
Zitat von Andreas Miethe;685129
Hier ein Manifest, dass das Programm ohne Virtualisierung (User-Modus) mit XP-Style laufen lässt.
Wird aber die Virtualisierung abgeschaltet, schlägt ein "Writeini" auf HKEY_LOCAL_MACHINE fehl und das Programm kackt wegen der zu geringen Rechte ab, wenn es nicht mit Adminrechten gestartet wird. Da für ist die Virtualisierung ja da, damit Programme ohne Elevation in die höheren Rechte funktionsfähig bleiben.
Zitat von Andreas Miethe;685129
Und ein Manifest, dass Adminrechte für das Programm anfordert, mit XP-Style.
Das Programm läuft mit diesem Manifest meines Wissens nach nur, wenn der Ausführende User auch wirklich ein Administrator ist. Möchte man Adminrechte haben, wenn dies möglich ist, muss man hier "requireAdministrator" durch "highestAvailable" ersetzen. -
Zitat von p. specht;685139
8O:stein::morse:
Wobei genau, helfe gerne. -
Zitat von AHT;685147
Wird aber die Virtualisierung abgeschaltet, schlägt ein "Writeini" auf HKEY_LOCAL_MACHINE fehl und das Programm kackt wegen der zu geringen Rechte ab, wenn es nicht mit Adminrechten gestartet wird. Da für ist die Virtualisierung ja da, damit Programme ohne Elevation in die höheren Rechte funktionsfähig bleiben.
Die Virtualisierung dient doch lediglich dazu, dass Vista abwärtskompatibel für "ältere" Programm ist.
Versucht so ein "älteres" Programm dahin zu schreiben, wo es nicht schreiben darf, wird umgeleitet.
So wird z.B. auch das Schreiben von meinen INI-Dateien im Installationsordner (C:\Programme\Meinordner\Setup.ini) umgeleitet auf "C:\Users\<mein_account>\AppData\Local\VirtualStore\Program Files\<Meinordner>\Setup.ini".
Habe ich möglicherweise auch ein Deinstallationsprogramm beigelegt um die Anwendung sauber zu deinstallieren, tauchen spätestens hier Probleme auf.
Das Deinstallationsprogramm kann die Ini-Datei nicht löschen, weil sie sie nicht findet.Ich, für meinen Fall, werde meine Programme standardmässig im User-Mode laufen lassen.
Ich weiss als Programmierer ja wenn ich irgendwo hinschreiben will wo ich Adminrechte brauche, und kann eine andere Prfrun32.exe mit Adminrechten benutzen.Zitat von AHT;685147Das Programm läuft mit diesem Manifest meines Wissens nach nur, wenn der Ausführende User auch wirklich ein Administrator ist. Möchte man Adminrechte haben, wenn dies möglich ist, muss man hier "requireAdministrator" durch "highestAvailable" ersetzen.
Das stimmt so nicht.
Bist Du nicht als Admin angemeldet kannst Du nur mit dem Programm weiterarbeiten, wenn Du das Administrator-Kennwort kennst. Du wirst aufgefordert das einzugeben.
Bist Du Admin musst Du nur bestätigen, dass Du weitermachen willst.Zitat von Frabbing;685100Böse Falle. Also warte ich noch mit einem Update des Betriebssystems.
Ob Du Dein Betriebssystem updatest oder nicht ist eigentlich gleich, als Programmierer willst Du doch Deine Software sicherlich auch Vista-Kompatibel haben.
Du wirst Dich also wohl oder übel mit dem Thema auseinandersetzen müssen.Übrigens kannst Du UAC (Benutzerkontensteuerung) auch abschalten.
-
Zitat von Andreas Miethe;685198
Die Virtualisierung dient doch lediglich dazu, dass Vista abwärtskompatibel für "ältere" Programm ist.
Versucht so ein "älteres" Programm dahin zu schreiben, wo es nicht schreiben darf, wird umgeleitet.
Ja, vollkommen richtig. Deshalb wäre es fatal, sein "älteres" Programm mit asInvoker auszustatten, wenn es versucht schreibend auf HKEY_LOCAL_MACHINE zuzugreifen, denn asInvoker verleiht, wie du hier richtig angemerkt hast, keine Adminrechte und so ziemlich jeder Schreibversuch auf HKEY_LOCAL_MACHINE verläuft wegen des DACL des Schlüssels und daraus resultierender fehlender Zugriffsrechte im Nirwana - so meinte ich das.
Zitat von Andreas Miethe;685198
So wird z.B. auch das Schreiben von meinen INI-Dateien im Installationsordner (C:\Programme\Meinordner\Setup.ini) umgeleitet auf "C:\Users\<mein_account>\AppData\Local\VirtualStore\Program Files\<Meinordner>\Setup.ini".
Habe ich möglicherweise auch ein Deinstallationsprogramm beigelegt um die Anwendung sauber zu deinstallieren, tauchen spätestens hier Probleme auf.
Danke für die Anmerkung!
Zitat von Andreas Miethe;685198
Das stimmt so nicht.
Bist Du nicht als Admin angemeldet kannst Du nur mit dem Programm weiterarbeiten, wenn Du das Administrator-Kennwort kennst. Du wirst aufgefordert das einzugeben.
Besten Dank, ich überprüfe das noch mal.
Zitat von Andreas Miethe;685198Ob Du Dein Betriebssystem updatest oder nicht ist eigentlich gleich, als Programmierer willst Du doch Deine Software sicherlich auch Vista-Kompatibel haben.
Du wirst Dich also wohl oder übel mit dem Thema auseinandersetzen müssen.
Das wichtige habe ich markiert! Bis XP konnte man programmieren wie unter Windows98, da quasi jeder ein Admin war. Ab Vista ist dem nicht mehr so.
Zitat von Andreas Miethe;685198
Übrigens kannst Du UAC (Benutzerkontensteuerung) auch abschalten.
Wer das tut, ist selbst schuld. Die ist nicht ohne Grund da. -
Zitat von AHT;685204
Besten Dank, ich überprüfe das noch mal.
Ja, stimmt. Die meisten meiner Programme wollen zwar Adminrechte, laufen mit eingeschränkter Funktion aber auch auf einem eingeschränkten Account ohne sich als Admin einzuloggen. Ich nehme deshalb bei meinen Proggies in der Regel highestAvailable oder arbeite mit Shellexec über einen Menüeintrag, um auch das Arbeiten mit eingeschränkter Funktion zu ermöglichen. Ist schon etwas her, dass ich requireAdministrator ausprobiert habe. -
MüllSchlucker + Andreas
Da hier ja zwei "im Doppelpack" so einiges schreiben, was mir zu hoch ist, eine Zwischenfrage von "Otto Normalverbraucher":;)
Als Beispiel mein "Quickstart-SE" -
Wird durch ein Setup in ein Verzeichnis kopiert (C:\Quickstart oder anderes) - In diesem Verzeichnis ist auch schon ein Unterverzeichnis. Beim 1. Start des Tools werden hier automatisch 3 Text-Dateien angelegt. - So war es bisher. Wird es jetzt so weit kommen, daß demnächst ohne Admin-Rechte diese Dateien nicht erstellt werden können
...und wenn "Ja", wie schalte ich dann in meinem Progrämmchen diese Admin-Rechte aus - Wenn das nicht möglich sein sollte, ist die ganze Programmierei für uns doch vorbei und Redmont hat es geschafft, uns außen vor zu lassen -
Zitat von horsthorn;685212
Wird es jetzt so weit kommen, daß demnächst ohne Admin-Rechte diese Dateien nicht erstellt werden können
Nein. das nicht. Wird dein Programm aber in den C:\Programme kopiert und irgendeiner kommt darauf, das Programm mal als Administrator auszuführen, findet das jetzt als Administrator gestartete Programm deine vorher erstellten Dateien evtl. nicht, denn C:\Programme\ ist ein "virtueller Ordner", dessen wirklicher Name C:\Program Files\ ist.
Zitat von horsthorn;685212
...und wenn "Ja", wie schalte ich dann in meinem Progrämmchen diese Admin-Rechte aus
Musst du gar nicht, du musst dir nur genau überlegen, wo du solche Dateien erstellst! (Shellordner nehmen evtl?)
Zitat von horsthorn;685212
Wenn das nicht möglich sein sollte, ist die ganze Programmierei für uns doch vorbei und Redmont hat es geschafft, uns außen vor zu lassen
Nö. Im Prinzip muss man nur begreifen, dass bestimmte Sachen, um die man sich bislang nicht kümmern musste, schon sehr lange existieren und oberflächlich verstehen, wie diese Sachen funktionieren - das ist alles.
Verstehen kann das im Prinzip jeder - für die Leute, die sich damit nicht beschäftigen wollen (weil es zu trocken ist :D) wird auf Dauer wohl das Programmieren vorbei sein - das ist richtig, denn die können nicht beurteilen, ob ein Programm vielleicht nur auf ihrem Rechner läuft oder woanders auch.
PS: In deinem Fall dürfte das Manifest von Andreas mit asInvoker angebracht sein .- solange dein Programm nicht versucht, in HKEY_LOCAL_MACHINE zu schreiben. -
Zitat von AHT;685241
PS: In deinem Fall dürfte das Manifest von Andreas mit asInvoker angebracht sein .- solange dein Programm nicht versucht, in HKEY_LOCAL_MACHINE zu schreiben.
Nein, hilft leider doch nicht. Das Problem liegt bei Zugriffsrechten des Ordner C:\Program files\. Benutzer haben hier standardmäßig keinen Vollzugriff, nur Administratoren. Wird dein Programm also ohne Adminrechte gestartet, darf es in den Ordner C:\Program files\ gar nicht schreiben und auch keine Dateien dort erstellen. Versucht es das trotzdem, wird auf den virtuellen Ordner umgeleitet, den Andreas hier genannt hat. Startest du das Programm mittels asInvoker Manifest aus C:\Program files\ bzw. C:\Programme\, dürfte es beim Erstellen der Dateien abstürzen (ungetestet). -
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!