Systemvariable in C++ setzen

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
 

Herakles

Profifragensteller
[LoN]Kamikaze schrieb:
Wohin schreibt sprintf denn?


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
 

Herakles

Profifragensteller
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
 

0815Chaot

FreeBSD/sparc64-Tüftler
Herakles schrieb:
wie kann ich ihn dazu zwingen, auf die Shell zuzugreifen?
Ü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...
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.
 

xbit

Well-Known Member
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
 

0815Chaot

FreeBSD/sparc64-Tüftler
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:
T

tib

Guest
0815Chaot schrieb:
Wäre mir neu, daß ein Prozeß im Speicher eines anderen Prozesses rumfummeln kann, selbst wenn er EUID 0 hat.
Da gibt es zwei schöne devices:
- /dev/mem
- /dev/kmem

Fraglich ist auch, wie ein Prozeß überhaupt irgendeine reelle Speicheradresse herausbekommen will.
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.
Wärst Du Dir da in Anbetracht des grundlegenden Verständnisses des OP sicher? :)
 

Herakles

Profifragensteller
@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!
 

ka46

Active Member
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? :)

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
 
T

tib

Guest
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.
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?
 

ka46

Active Member
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?

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
 
T

tib

Guest
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]
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.
 

ka46

Active Member
Hallo

Maledictus schrieb:
Habt ihr mal drüber nachgedacht was gdb tut?

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
 
Oben