Systemvariable in C++ setzen

Herakles

Herakles

Profifragensteller
Moin!

Ich möchte in C++ gern eine Umgebungsvariable setzen, leider funktioniert dieser Code hier nicht:

Code: 
char temp[500];
sprintf(temp,"export TOLL=1");
system(temp);

Die Umgebungsvariable TOLL ist nach diesem Programm nicht gesetzt. Wieso nicht?

Danke, Herakles
 
[LoN]Kamikaze schrieb:
Wohin schreibt sprintf denn?
Zum Vergrößern anklicken....


Ehm.... ja, in temp, oder was? Schiebt nur den Inhalt, der dahinter steht in die Variable "temp" um anschliessend den Systemaufruf über "temp" zu machen... übliche Vorgehensweise hier im Hause...

?!?!?!????????

Oh, grade erst gesehen: @ paefchen: wie kann ich ihn dazu zwingen, auf die Shell zuzugreifen?

Oder mal abgesehen von meinem Vorschlag: wie könnte sowas funktionieren, was ich will? WIE ich dahin komme, ist mir eigentlich Sche....egal
 
Letzte Frage:

Wie ist wohl die Syntax für eine Variableeinbindung?

Etwa so etwas soll passieren:

Code: 
unsigned int i=0;
putenv("PVM_VMID=%d",i);

Klappt so NATÜRLICH nicht...

Herakles
 
Herakles schrieb:
wie kann ich ihn dazu zwingen, auf die Shell zuzugreifen?
Zum Vergrößern anklicken....
Überhaupt nicht. Du kannst das Environment des Elternprozesses NIE verändern! Ein Prozeß kann nur seine eigene Umgebung manipulieren, die dann ggf. seine Kinder erben. Auch ist es bei diversen exec(3)-Varianten möglich, ein entsprechendes Array als neues Environment des Kindes zu übergeben. Aber "nach oben" hin in der Prozeßstruktur ist das NICHT möglich.

Herakles schrieb:
putenv("PVM_VMID=%d",i);

Klappt so NATÜRLICH nicht...
Zum Vergrößern anklicken....
Selbstverständlich nicht. putenv(3) erwartet ausschließlich einen String. Den mußt du dir dann erstmal mit sprintf(3) zusammenbauen, da kannst du obige Syntax nämlich verwenden.

Vielleicht solltest du dir das Thema einmal anhand von Grundlagenliteratur erarbeiten. "Advanced Programming in the Unix Environment" ist sehr gut geeignet, allerdings auch nicht ganz billig.
 
system() wird nicht helfen, weil es dazu dient einen Prozess ausfuehren. Das hat nichts mit dem aktuell laufenden Programm zu tun.

Guck Dir setenv() mal an, damit sollte das funktionieren.
Wichtig: putenv() und setenv() arbeiten unterschiedlich.

Und um das Ganze noch sicher zu machen und auf sprintf() zu verzichten, wirf einen Blick auf std::stringstream, da brauchst Du Dir keine Gedanken machen, dass der Buffer gross genug ist.

HTH
 
Wäre mir neu, daß ein Prozeß im Speicher eines anderen Prozesses rumfummeln kann, selbst wenn er EUID 0 hat. Fraglich ist auch, wie ein Prozeß überhaupt irgendeine reelle Speicheradresse herausbekommen will.

Im übrigen hat das aber auch nichts mit der Frage des OP zu tun, da dieser mit Sicherheit nicht vor hatte, den Kernel zu frisieren.
 
Zuletzt bearbeitet:
0815Chaot schrieb:
Wäre mir neu, daß ein Prozeß im Speicher eines anderen Prozesses rumfummeln kann, selbst wenn er EUID 0 hat.
Zum Vergrößern anklicken....
Da gibt es zwei schöne devices:
- /dev/mem
- /dev/kmem

Fraglich ist auch, wie ein Prozeß überhaupt irgendeine reelle Speicheradresse herausbekommen will.
Zum Vergrößern anklicken....
Bei Linux würde ich einen tieferen Blick in /proc werfen.
Bei FreeBSD muss ich noch mal genauer nachsehen.
/proc ist per Default inaktiviert, aber all zuschwer dürfte es nicht ausfallen (mit EUID 0).

Im übrigen hat das aber auch nichts mit der Frage des OP zu tun, da dieser mit Sicherheit nicht vor hatte, den Kernel zu frisieren.
Zum Vergrößern anklicken....
Wärst Du Dir da in Anbetracht des grundlegenden Verständnisses des OP sicher? :)
 
@tib: Mir ist es viel zu anstrengend, angemessen auf die verbale Minderwertschätzung im letzten Satz Deines Posts zu antworten.

Allen anderen: Danke für die Hilfe!
 
Hallo

tib schrieb:
Da gibt es zwei schöne devices:
- /dev/mem
- /dev/kmem


Bei Linux würde ich einen tieferen Blick in /proc werfen.
Bei FreeBSD muss ich noch mal genauer nachsehen.
/proc ist per Default inaktiviert, aber all zuschwer dürfte es nicht ausfallen (mit EUID 0).


Wärst Du Dir da in Anbetracht des grundlegenden Verständnisses des OP sicher? :)
Zum Vergrößern anklicken....

Ich bin zwar mit dem VM-Subsystem von FreeBSD nicht so richtig vertraut, da ich eher mit NetBSD arbeite, aber ich bin der Meinung, dass, solltest du versuchen den Speicherbereich eines anderen Prozesses zu manipulieren, das mit einm segmentation violation des VM Systems Quitiert wird. Das Pasiert unabhaenig ob ich root oder sonst wer bin.

MfG

Lars
 
ka46 schrieb:
Ich bin zwar mit dem VM-Subsystem von FreeBSD nicht so richtig vertraut, da ich eher mit NetBSD arbeite, aber ich bin der Meinung, dass, solltest du versuchen den Speicherbereich eines anderen Prozesses zu manipulieren, das mit einm segmentation violation des VM Systems Quitiert wird. Das Pasiert unabhaenig ob ich root oder sonst wer bin.
Zum Vergrößern anklicken....
Wo Du gerade NetBSD erwähnst.

In diesem ist es nicht direkt möglich die MAC-Addresse eines Interfaces zu ändern.

Nach etwas googlen bin ich auf ein Programm (sea.c) gestossen,
dass für OpenBSD geschrieben wurde als es dort auch noch nicht möglich war.

Mit zwei minimalen Anpassungen, die ich übrigens auch im Forum beschrieben habe,
war es möglich das Programm unter NetBSD erfolgreich auszuführen.

Wenn es als schon im Kernel funktioniert, warum sollte es beim Rest ein Problem darstellen?
 
Hallo
tib schrieb:
Wo Du gerade NetBSD erwähnst.

In diesem ist es nicht direkt möglich die MAC-Addresse eines Interfaces zu ändern.

Nach etwas googlen bin ich auf ein Programm (sea.c) gestossen,
dass für OpenBSD geschrieben wurde als es dort auch noch nicht möglich war.

Mit zwei minimalen Anpassungen, die ich übrigens auch im Forum beschrieben habe,
war es möglich das Programm unter NetBSD erfolgreich auszuführen.

Wenn es als schon im Kernel funktioniert, warum sollte es beim Rest ein Problem darstellen?
Zum Vergrößern anklicken....

Weil es im kvm Interface meines wissens nicht implementiert ist:

"...Unlike their SunOS counterparts, these functions cannot be
used to read or write process address spaces ..." [1]


MfG

Lars
[1] http://netbsd.gw.com/cgi-bin/man-cgi?kvm_read++NetBSD-current
 
ka46 schrieb:
Weil es im kvm Interface meines wissens nicht implementiert ist:
"...Unlike their SunOS counterparts, these functions cannot be
used to read or write process address spaces ..." [1]
Zum Vergrößern anklicken....
Mist, ich habe vor kurzem bei Aufräumen meine NetBSD 3.0 qemu Installation entsorgt.
Wenn ich eine neue habe werde ich mir das Ganze mal in Ruhe ansehen.
 
Hallo

Maledictus schrieb:
Habt ihr mal drüber nachgedacht was gdb tut?
Zum Vergrößern anklicken....

Ich habe mal etwas gesucht, der gdb fuehrt einen Syscall ptrace(2) aus und der Kern veraendert den Adressraum, nicht der gdb Prozess selbst. Wenn ich falsch liegen sollte, was moeglich ist, berichtigt mich bitte oder gebt mit links zu den entsprechenden Informationen, damit ich das richtig verstehe.

MfG

Lars
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben