system() nicht zuverlässig
Martin Collins
ich benutze system() in meinem Daemon um eine Skript auszuführen. Vielleicht
einmal
in 500 wird die Skript nicht ausgeführt. system() liefert aber kein
Fehlercode zu sagen
was passiert ist. Das Unix ist Sco Openserver 5.0.5.
Weiß jemand Rat?
Danke,
Martin.
Holger Friese
Warum der system()-Call nicht ausgeführt wird, kann ich leider nicht sagen.
Aber wie wäre es denn mit fork() und exec() statt system()?
Shell-Scripte werden von Shells ausgeführt, also müsste sowas wie
execl("/bin/sh", "/bin/sh", <shellscript>)
doch auch den gewünschten Erfolg bringen - falls der Fehler
wirklich nur an system() liegt...
>Danke,
>
>Martin.
Gruß
Holger
--
_____________________________________________________________
NewsGroups Suchen, lesen, schreiben mit http://netnews.web.de
Felix von Leitner
> ich benutze system() in meinem Daemon um eine Skript auszuführen.
Du bist eine Gefahr für dich und deine Umgebung.
Lasse den Daemon von jemandem schreiben, der das Unix-API genug
verstanden hat, um system() nicht einzusetzen.
> Vielleicht einmal in 500 wird die Skript nicht ausgeführt. system()
> liefert aber kein Fehlercode zu sagen was passiert ist.
Nächstes Mal liest du die man page, bevor du Leute im Usenet belästigst,
OK?
> Das Unix ist Sco Openserver 5.0.5.
> Weiß jemand Rat?
PEBKAC.
Felix
Dirk Ohme
> Du bist eine Gefahr für dich und deine Umgebung.
Bist Du schon wieder mit dem falschen Fuss aufgestanden? Wenn Du schon
andere als eine Gefahr für die Allgemeinheit darstellst, dann begründe
wenigstens warum ... denn:
>> Das Unix ist Sco Openserver 5.0.5.
Warum sollte dort system() ein Problem für Dämonenprozesse sein?
Begründung!
So long,
-+- Dirk -+-
Rainer Weikusat
> >> Das Unix ist Sco Openserver 5.0.5.
>
> Warum sollte dort system() ein Problem für Dämonenprozesse sein?
> Begründung!
Weil es eine shell mit Eingaben von einer nicht vertrauenswürdigen
Quelle füttert.
--
SIGSTOP
Alexander Bartolich
> [...]
> Warum sollte dort system() ein Problem für
> Dämonenprozesse sein?
man system (glibc-2.1.3-22)
# [...]
# Do not use system() from a program with suid or sgid priv
# ileges, because strange values for some environment vari
# ables might be used to subvert system integrity. Use the
# exec(3) family of functions instead, but not execlp(3) or
# execvp(3). system() will not, in fact, work properly from
# programs with suid or sgid privileges on systems on which
# /bin/sh is bash version 2, since bash 2 drops privileges
# on startup. (Debian uses a modified bash which does not
# do this when invoked as sh.)
> Begründung!
Ich sehe keine Logik im Verhalten Felix von Leitners.
Seine Postings sind voll Aggression, bis zum Haß.
Allerdings würde ich bei dieser Einstellung die Leute
einfach dumm sterben lassen, und die Frage ignoriern.
Besonders produktiv ist sein Stil auf keinen Fall.
--
Hi! I'm Clippy, your personal assistant for MS-Latrine 1.0
You look like you need a piss. May I give a helping hand?
Benedikt Meurer
<usenet-...@fefe.de>:
>> ich benutze system() in meinem Daemon um eine Skript auszuführen.
> Du bist eine Gefahr für dich und deine Umgebung. Lasse den Daemon von
> jemandem schreiben, der das Unix-API genug verstanden hat, um system()
> nicht einzusetzen.
Vielleicht solltest du einmal darüber nachdenken eine kalte Dusche zu
nehmen, bevor du das nächste Mal deinen Newsreader startest!
>> Vielleicht einmal in 500 wird die Skript nicht ausgeführt. system()
>> liefert aber kein Fehlercode zu sagen was passiert ist.
> Nächstes Mal liest du die man page, bevor du Leute im Usenet belästigst,
> OK?
Fragt sich nur, wer hier belästigt.
>> Das Unix ist Sco Openserver 5.0.5.
>> Weiß jemand Rat?
man fork
man exec
Das sollte das Problem lösen.
Mit freundlichen Grüßen
Benedikt Meurer
Dirk Ohme
>> Warum sollte dort system() ein Problem für Dämonen-
>> prozesse sein? Begründung!
> Weil es eine shell mit Eingaben von einer nicht
> vertrauenswürdigen Quelle füttert.
Wo schreibt er, dass die Daten direkt vom Übertragungskanal kommen? Es
könnte ja auch sein, dass er eine auf dem Server fest kodierte Anweisung
ausführen möchte und keine Zeichenkette direkt zur Shell senden. Bspw.
über X10 eine Hausbeleuchtung einschalten, aber er hat keine API,
sondern nur Kommandozeilentools.
Ich verstehe ja Eure Sicherheitsbedenken - aber wir sind hier in
*.programming und nicht *.security.* - also nicht gleich alles
verteufeln. In einer abgeschotteten Umgebung kann man ja auch Dinge tun,
die man sonst besser nicht machen würde ...
Rainer Weikusat
> >> Warum sollte dort system() ein Problem für Dämonen-
> >> prozesse sein? Begründung!
> > Weil es eine shell mit Eingaben von einer nicht
> > vertrauenswürdigen Quelle füttert.
>
> Wo schreibt er, dass die Daten direkt vom Übertragungskanal kommen?
Wo schreibt er, das sie das nicht tun?
> Ich verstehe ja Eure Sicherheitsbedenken - aber wir sind hier in
> *.programming und nicht *.security.* - also nicht gleich alles
> verteufeln. In einer abgeschotteten Umgebung kann man ja auch Dinge tun,
> die man sonst besser nicht machen würde ...
zB 'gets' [SCNR]
--
SIGSTOP
Dirk Ohme
>> Wo schreibt er, dass die Daten direkt vom
>> Übertragungskanal kommen?
> Wo schreibt er, das sie das nicht tun?
*seufz*
"Unter der Annahme, dass Du ... machst, würde ich Dir empfehlen ..." ;-)
>> In einer abgeschotteten Umgebung kann man ja auch Dinge
>> tun, die man sonst besser nicht machen würde ...
> zB 'gets' [SCNR]
Sorry, kein Prüfen des zur Verfügung stehenden Zielspeichers ist nicht
nur aus Sicherheitsgründen bedenklich, es ist schlichtweg ärgerlich.
"Dr. Watson" lässt grüssen ... auch im abgeschotteten System ;-)
Okay, jetzt bitte keine Diskussion vom Schlag "prüfst Du dann auch den
Return Code von fclose()?" - nee, denn da sind selten SIGSEGV zu
erwarten *eg*
Rainer Weikusat
> >> Wo schreibt er, dass die Daten direkt vom
> >> Übertragungskanal kommen?
> > Wo schreibt er, das sie das nicht tun?
>
> ;-)
Soll mir recht sein ;-).
--
SIGSTOP