Sind Umgebungsvariablen unsicher?

[Matze]

Moin,

vorhin habe ich mich gefragt, wieso hier des öfteren gefragt wird, wie man den angemeldeten Benutzernamen unter Windows ausliest (ich weiß, es können mehrere angemeldet sein, aber ich meine nun den normalen Fall, dass eine Person am Rechner sitzt und niemand übers Netzwerk und ähnlichem darauf zugreift).

Oftmals stoße ich auf Source wie diesen, der unter gewissen Umständen nicht funktioniert. Ähnliche Ansätze sind hier auch anzutreffen.

Nun stehen solche Infos doch auch in den Umgebungsvariablen. Lassen sich diese leicht manipulieren oder wieso wird allgemein nicht einfach darauf zugegriffen?

Um auf das eben genannte Beispiel zurückzukommen, ginge dies in Delphi ja einfach mittels:

Delphi-Quellcode:

GetEnvironmentVariable('USERNAME')

Evtl. habe ich falsch gesucht, doch zu diesem Thema konnte ich nichts finden und ich bin überzeugt davon, dass es einen Grund hat diese komplizierteren Vorgehensweisen zu nutzen.

Grüße,
Matze

[Dezipaitor]

Man kann die Umgebungsvariable täuschen, indem man sie einfach ändert. Über die Kommanodzeile mit "set".

Den Benutzername kannst du aber auch so erhalten:
http://blog.delphi-jedi.net/2008/03/...rom-a-service/

[Christian Seehase]

Moin Christian,

Zitat:

Zitat von Dezipaitor

Man kann die Umgebungsvariable täuschen, indem man sie einfach ändert. Über die Kommanodzeile mit "set".

Hast Du auch mal ausprobiert, wie lange diese Änderung hält?
So eine Änderung wirkt nur in dieser einen Konsole, und daraus aufgerufenen Prozessen, da sie das Environment erben.
Eine Umgebungsvariable USERNAME als solche existiert auch nicht, sondern wird, IMHO, initial durch den Aufruf von GetUserName (bzw. GetUserNameEx) gefüllt.
Die "echten" Umgebungsvariablen findet man unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\Environment

Anzeigen und ändern lassen sich diese auch über die Systemeigenschaften, und dann wirken sich Änderungen aus.

[Luckie]

Zitat:

Zitat von Matze

Oftmals stoße ich auf Source wie diesen, der unter gewissen Umständen nicht funktioniert. Ähnliche Ansätze sind hier auch anzutreffen.

Es gibt noch GetUsername ohne das "Ex". Damit hatte ich noch nie Probleme.

[nicodex]

Zitat:

Zitat von Christian Seehase

Moin Christian,

Zitat:

Zitat von Dezipaitor

Man kann die Umgebungsvariable täuschen, indem man sie einfach ändert. Über die Kommanodzeile mit "set".

Hast Du auch mal ausprobiert, wie lange diese Änderung hält?

So eine Änderung wirkt nur in dieser einen Konsole, und daraus aufgerufenen Prozessen, da sie das Environment erben.

Diese Art des Überschreibens von Umgebungsvariablen hat durchaus seine Daseinsberechtigung :)
Ein möglicher Anwendungsfall: Man möchte, dass ein Setup ein alternatives TEMP-Verzeichnis verwendet (in %TEMP% ist zu wenig Platz oder der Zugriff ist zu langsam).

Zitat:

Zitat von Christian Seehase

Die "echten" Umgebungsvariablen findet man unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\Environment

Anzeigen und ändern lassen sich diese auch über die Systemeigenschaften, und dann wirken sich Änderungen aus.

Die Änderungen werden nur von den Programme bemerkt, die auf die entsprechende Nachricht reagieren, die das Systemsteuerungselement an alle schickt (der Windows Explorer behandelt die Nachricht - andere Programme nicht unbedingt).

[Christian Seehase]

Moin Nico,

auch mal wieder da ;-)

Zitat:

Zitat von nicodex

Diese Art des Überschreibens von Umgebungsvariablen hat durchaus seine Daseinsberechtigung :)
Ein möglicher Anwendungsfall: Man möchte, dass ein Setup ein alternatives TEMP-Verzeichnis verwendet (in %TEMP% ist zu wenig Platz oder der Zugriff ist zu langsam).

Ich wollte eigentlich nur darauf hinaus, dass man die Umgebungsvariablen nicht einfach per SET so ändern kann, dass es sich auf andere laufende Prozesse auswirkt, sondern nur auf welche, die dieses geänderte Environment vom Aufrufer erben.

Zitat:

Zitat von nicodex

Die Änderungen werden nur von den Programme bemerkt, die auf die entsprechende Nachricht reagieren, die das Systemsteuerungselement an alle schickt (der Windows Explorer behandelt die Nachricht - andere Programme nicht unbedingt).

Wobei es sich auf alle Programme auswirkt, die nach der Änderung per Systemsteuerung, aus dem Explorer, oder der Konsole gestartet werden.
Die angesprochene "Umgebungsvariable" USERNAME könnte man wohl nur durch Änderung im Environment des Explorers umbiegen.
Hmmm. :gruebel: Das muss ich mal ausprobieren ;-)

[Muetze1]

Kleiner Hinweis: GetTempPath() der WinAPI ist eine API Funktion und greift als erstes auf die Environmentvariablen zu.

[Dezipaitor]

Also env sind net unbedingt als unsicher anzusehen.
Es ist sehr nützlich einige Variablen zu ändern. Bei Benutzername sollte man aber vorsichtig sein. Je nachdem, was damit in der App gemacht wird, kann man dumme Sachen machen. Deine App wäre nicht die erste, die abstürzt, wenn man eine Variable ungeschickt verändert.

[SirThornberry]

Der Grund warum ich nicht auf die Umgebungsvariablen zugreife ist der das ich nicht weiß ob sie in der nächsten Windowsversion noch genau so heißen. Da ist die Verwendung der Apifunktion doch bedeutend sicherer. Das Beispiel des Tempverzeichnisses ist schon perfekt. Seit XP (oder so ähnlich) gibt es zusätzlich ein Temp Verzeichnis für jeden user und wenn ich einfach das alte Temp-Verzeichnis verwende kanns fix passieren das ich dort gar keinen Zugriff habe.

[nicodex]

Zitat:

Zitat von Christian Seehase

Die angesprochene "Umgebungsvariable" USERNAME könnte man wohl nur durch Änderung im Environment des Explorers umbiegen.
Hmmm. :gruebel: Das muss ich mal ausprobieren ;-)

Ist bei WM_SETTINGCHANGE dokumentiert:

Zitat:

To effect a change in the environment variables for the system or the user, broadcast this message with lParam set to the string "Environment".