Abfragen von Systeminformationen

[stefan-tiger]

Hallo,

wie Frage ich Informationen aus meinem Betriebsystem Linux mit C/C++ am besten ab?

Habe jetzt schon einige Tage herumgedoktert und für wenige Dinge Systemaufrufe, für die meisten Dinge Prorgammaufrufe per "popen()" gemacht und die Ausgabe geparst.

Das ganze sieht aus wie ein Shell-Script in C/C++ Syntax.

Gibt es nicht ne einfachere und elegantere Möglichkeit?

Ich denke da an Windows und die sog. Registrierungsdatenbank.

Ich möchte keine externen Prorgamme benutzen, da mein Prorgamm unabhängig sein soll. Ich möchte aber auch keine Verrenkungen machen über 10 Ecken irgendwelche "simplen" Infos aus dem Betribsystem rauszuquetschen.

Die Daten die ich brauche muss das Betriebsystem ja selbst benutzen, also hoffe ich, daß es irgendwo eine gut strukturierte Zugriffsmöglichkeit gibt.

Wer andere Threads von mir kennt, weiß daß ich immernoch dran bin "simple" Abfragen zu machen, nach der Stuktur:

Rechnername, Domainname, Gateway, DNS-Server?
Welche Netzwerkinterfaces (Device-Namen) stecken im Rechner?
Was sind MAC, Hersteller & Modell, Typ (Token-Ring,Ethernet oder WLAN), Anschluss (ISA, PCI, USB), Geschwindigkeiten (und Duplexmodus) , aktuelle Geschw., Netzwerkkabel eingesteckt der Netzwerkinterfaces?
Welche IP Daten haben die Netzwerkinterfaces (IP-Adresse(n), Netzmaske)?

Bei WLAN gibts dann noch mehr zu tun...

Der Kernel muss diese Dinge ja intern verwalten. Das möchte ich "ganz eifnach" auslesen.

Was mich "krank" macht: Ich hab mir schon den Sourcecode zahlreicher Prorgamme angeschaut, und JEDES ermittelt diese Daten völlig anders.

Gibt es keinen "Standard"-Weg?

Es ist nicht sinnvoll, wenn ich jetzt die Funktionen ein weiteresmal implementiere.

[mehlvogel]

Eigentlich sollte es unter Linux unter /proc und /sys genügend Informationen geben, ob es vielleicht sogar ein direkteres Kernelinterface gibt, weiß ich allerdings nicht.

[Lord Kefir]

Ich würde einfach mal in /proc herumschauen. Ich denke an viele Infos kommst Du anders gar nicht heran - ausser Du programmierst im Kernelspace, was ich als übertrieben einschätzen würde... schließlich sind die Informationen ja schon da.

Mfg, Lord Kefir

[anda_skoa]

Für ein paar der Sachen gibt es Funktionen, etwa gethostname oder getdomainname
Nameserver stehen in /etc/resolv.conf

Für die meisten Hardware Eigenschaften arbeitet man am besten über HAL [1], welcher noch den zusätzlichen Vorteil hat, daß man sich über Änderungen informieren lassen kann.

Ciao,
_

[1] http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD

[bischi]

Kannst du für die ganzen Netzwerkinformationen nicht Systemprogramme wie ifconfig und ähnliche brauchen? Die müssen ja für funktionierende Netzwerke sowieso installiert sein - es dürfte also kein Problem sein, solche Programme als Voraussetzung zu betrachten. (Ich meine: Der Kernel ist ja auch ein "externes Programm").

MfG Bischi

[stefan-tiger]

Kannst du für die ganzen Netzwerkinformationen nicht Systemprogramme wie ifconfig und ähnliche brauchen? ...

Doch, das machen auch viele und das stört mich eben.

Ich will doch nicht in C/C++ Programmieren um dann wieder in den Stil von Shellscripten zu gelangen.

Ich möchte eine C/C++ Funktion aufrufen und Rückgabewerte erhalten.

Ich möchte nicht über das Bestreibsystem andere Prorgamme in einer Shell aufrufen lassen um deren Output zu parsen, was nämlich "popen" und "KProcess" machen.

Aber anscheinend ist diese, aus C/C++-Sicht äußerst häßliche, Methode leider gang und gebe, z.B. bei "knemo" oder "knetload".

Das einzige Netzwerk-Tool was wohl nicht "ifconfig" aufruft ist "ifconfig" selber :(

Ich hab mir jetzt das Buch "Linux, Unix, Systemprogrammierung" von Helmut Herold geholt, leider nur 2.te Auflage. Mal sehn wie weit ich damit komm.

[BinEinGast]

Doch, das machen auch viele und das stört mich eben.

Ich will doch nicht in C/C++ Programmieren um dann wieder in den Stil von Shellscripten zu gelangen.

Ich möchte eine C/C++ Funktion aufrufen und Rückgabewerte erhalten.
[...]


das wird jetzt kein wirklich konstruktiver beitrag, aber was ist am scripten denn so schlimm? im grunde machst du dir nur überflüssige arbeit. natürlich sollte man alles mal von hand gemacht haben, aber ob man eine betriebssystemsmethode oder ein dienstprogramm aufruft, macht für das verständnis keinen unterschied. um bestimmte ziele zu erreichen, ist das aufrufen von dienstprogrammen nun mal komfortabler

[peschmae]

Es ist potentiell heikler - da hat er allerdings schon recht. Eine schöne saubere API wäre da bei weitem zu bevorzugen - wenn es sie denn gäbe.

MfG Peschmä

[RHBaum]

um bestimmte ziele zu erreichen, ist das aufrufen von dienstprogrammen nun mal komfortabler
In vielen Faellen ist das sogar von der Aufgabenstellung her ausgeschlossen !
system und exec aufruafe haben eklatante sicherheitsprobleme ... rein von der Logik her.
Performance ist auch nen problem ... jedesmal den prozess ueberlagern, die komplette umgebung sichern ... ist ned wirklich performant wenn man nen simplen aufruf taetigen will ...
Es wird meist nie standardkonform ....

Systeminformationen abrufen unter Linux iss prinzipiell nen "heikles" Thema ...
Warum ?
Einige Informationen sollen und duerfen userspace programme nicht bekommen.
Was will denn ein userspace programm bitte mit der MAC adresse ? Ausser sie zu irgendwas zu missbrauchen ? Es gibt ne menge interfaces die tcp/ip koennen und sowas gar nicht haben ... virtuelle interface ???
Andere sachen sind auch absichtlich nicht einfach zugaenglich, weil sie dynamisch sein koennten, und implementationsdetails eines anderen protokolls sind.
Z.B. Gateway fuer bestimmte netze ... du liest den aus, arbeitest damit ... und zoff ... was ist wenn da nen routed mit laeuft der dir den gateway im betrieb umschaltet ?

Du solltest dir genau ueberlegen was du machen willst.
Fuer alles, was fuer normale user linux programme nach standard vorgesehen ist, gibt es im Posix standard ne funktion.
Alles was darueber hinausgeht, sind hacks fuer bestimmte besondere aufgabenstellungen. Die sind dann nich mehr posix standard sondern du schiesst dich auf nen bestimmtes system (Linux) oder gar ne bestimmte distribution ein .... und das sollt man vermeiden.

Ciao ...

[BinEinGast]

In vielen Faellen ist das sogar von der Aufgabenstellung her ausgeschlossen !

warum? alles was eine os-funktion kann, kann ein dienstprogramm auch (alleine weil das dienstprogramm die os-funktion aufrufen kann) zu performance und/oder sicherheit siehe unten.



system und exec aufruafe haben eklatante sicherheitsprobleme ... rein von der Logik her.

an die meisten informationen von system und / oder exec-aufrufen musst du gelegentlich aber kommen. das betriebssystem stellt auch nur solche funktionien zur verfügung, die der 'nutzer' auch nutzen können soll. falls sich dadurch sicherheitslücken auftuen, ist es aufgabe der os-coder diese zu schließen und nicht einfach gezielt zugriff auf informationen zu unterbinden, an die man anderweitig doch kommen kann.



Performance ist auch nen problem ... jedesmal den prozess ueberlagern, die komplette umgebung sichern ... ist ned wirklich performant wenn man nen simplen aufruf taetigen will ...
Es wird meist nie standardkonform ....
[...]

warum? das auslesen der informationen hat doch konstante laufzeit. man liest doch auch nicht, wenn man zugriff auf eine datei im dateisystem haben möchte, den boot-record, die i-nodes, etc. von neuem aus, sondern speichert sich diese daten irgendwo. den zeitlichen aufwand halte ich durchaus für vertretbar

scripten hat gegenüber 'hard-coden' auch den vorteil, daß es wirklich absolut platformunabhängig läuft und du dich nicht auf bestimmte betriebssysteme / distributionen einschießen mußt.



Was will denn ein userspace programm bitte mit der MAC adresse ? Ausser sie zu irgendwas zu missbrauchen ? Es gibt ne menge interfaces die tcp/ip koennen und sowas gar nicht haben ... virtuelle interface ???

ich hab den TCP/IP-header grad nicht im kopf, aber vielleicht möchtest du deine eigenen protokolle implementieren, weil dir z.b. der tcp-header zu aufgeplustert ist, dir UDP aber zu schlank ist.
eine andere möglichkeit wäre z.b., daß du ein tool schreiben möchtest, mit dem du remote einen DHCP-server konfigurieren kannst. um deinen aktuelle netzwerkkarte in die datenbank eintragen zu können, mußt du an die MAC ...



Es ist potentiell heikler - da hat er allerdings schon recht. Eine schöne saubere API wäre da bei weitem zu bevorzugen - wenn es sie denn gäbe.

jup

[RHBaum]

warum? alles was eine os-funktion kann, kann ein dienstprogramm auch
Eher andersrum ^^ alles was ein dienstprogramm kann sollt eine Api vom BS auch oder ^^ wobei man hier sehr wohl unterscheiden muss, auf welchen Standard man sich runner begibt (Posix, Distri )


das betriebssystem stellt auch nur solche funktionien zur verfügung, die der 'nutzer' auch nutzen können soll.
und du willst programme schreiben die drueber hinausgehen ? dann solltest aber auch damit leben, dass dein programm nicht mehr portabel und plattformunabhaengig bleibt ....


alls sich dadurch sicherheitslücken auftuen, ist es aufgabe der os-coder diese zu schließen
wenn sich diese Luecken durch die tools oder die Information auftun, sicherlich ... ueber die rede ich nicht, sondern ueber die die ein exec/system aufruf als solches immer mit sich bringt, egal was man da genau aufruft ....


warum? das auslesen der informationen hat doch konstante laufzeit. man liest doch auch nicht, wenn man zugriff auf eine datei im dateisystem haben möchte, den boot-record, die i-nodes, etc. von neuem aus, sondern speichert sich diese daten irgendwo. den zeitlichen aufwand halte ich durchaus für vertretbar
Wenn man die sache einmal macht ... ok
wenn man die infos aber 20 mal die sekunde braucht ....
und ich red ned um overhaed den das hilfsprogramm brauch, sondern overhead den dein programm braucht um den eigenen prozess fuers hilfsprogramm zu ueberlagern ...
zum besipiel ruf mal zigtausend mal gethostbyname auf, oder parse zigtausend mal den ausgabestream von nem exec ("nslookup irgendwas").


scripten hat gegenüber 'hard-coden' auch den vorteil, daß es wirklich absolut platformunabhängig läuft und du dich nicht auf bestimmte betriebssysteme / distributionen einschießen mußt.
Ich behaupte nicht das scripts keine vorteile haben ... wenn ein script meine anforderungen erfuellt, ist es meist sogar die bessere variante, weil es eben weniger entwicklungszeit verbraucht hat, aber darum gehts hier wohl nicht oder ?


ich hab den TCP/IP-header grad nicht im kopf, aber vielleicht möchtest du deine eigenen protokolle implementieren, weil dir z.b. der tcp-header zu aufgeplustert ist, dir UDP aber zu schlank ist.
Das Osi Schichtmodell haett mir mein Informatiklehrer bei der Frage um die Ohren gehauen ^^
Im ernst, wenn du TCP/IP im speziellen falle UDP verwenden willst, solltest du dich an konventionen halten. Und eine davon ist, das die MAC eben Implementationsdetail ist ... nicht mal auf TCP/IP schicht, die iss schon zu hoch dafuer sondern auf Datenuebertragungsschicht.
Wenn du Anwendungen schreibst die TCP/IP frames verwenden und gleichzeitig MAC adressen auswerten, solltest du nicht davon ausgehen, dass deine anwendung auf anderen systemen oder bei paar umkonfigurierungen noch laeuft ^^


mit dem du remote einen DHCP-server konfigurieren kannst
schreibst du programme oder Tools zur systemverwaltung ^^ das ist nen unterschied, und zwar nen gewaltiger ^^
und grad fuer solche zwecke wuerd ich sogar scripts bevorzugen, weil der entwicklungsaufwand geringer ist und ich mir bei solchen benutzerdefiniert zurechtgestrickten loesungen sicher sein kann, dass die nur bei mir funktionieren, dann waer mir der aufwand fuern c/c++ prog zu hoch ...

Ciao ...

[anda_skoa]

warum? das auslesen der informationen hat doch konstante laufzeit.


Konstant schon, aber das Starten des externen Executables ist Overhead und das Parsen des Outputs auch.

Abgesehen davon ist das Parsen eines Programmoutputs, der nicht für maschinelle Weiterverarbeitung gedacht ist, also keinen definierten Konventionen folgt, immer eine problematische Sache. Thematik Screenscraping.

Die sauberste Lösung unter Linux ist derzeit sicher HAL.

Ciao,
_

[stefan-tiger]

Ich formuliers mal ganz einfach:

Wenn ich statt Kernelfunktionen (bzw. Systemfunktionen) den Output von externen Prorgammen parsen will dann brauche ich etliche Dinge die ich vielleicht nicht habe oder von denen ich vielleicht nicht abhängig sein will.

Ausserdem ist das Output parsen mitunter aufwändig und fehleranfällig.
Ganz zu schweigen von wenn auf einem anderen PC auf dem das Prorgamm laufen soll irgendwelche Konsolenprogramme verschiede Schalter nicht haben weil ihre Version zu alt ist, oder der Output anders ist usw. usw.

Und in "speziellen" Fällen, wie z.B. Linux auf nicht PC-artigen-Systemen betreiben hat man auch vieles einfach nicht verfügbar, wie ne shell, geschweige denn "ifconfig".

[anda_skoa]

Nachdem du es lieber selber implementierst anstatt auf etablierte Mechanismen zu setzen, schlage ich vor, du siehst dir den Code des etablierten Systems an, also den Source von hald

http://freedesktop.org/wiki/Software_2fHalBuildInstructions

Ciao,
_

[stefan-tiger]

Nachdem du es lieber selber implementierst anstatt auf etablierte Mechanismen zu setzen, schlage ich vor, du siehst dir den Code des etablierten Systems an, also den Source von hald

http://freedesktop.org/wiki/Software_2fHalBuildInstructions

Ciao,
_

Werd ich machen, dankeschön. Aber zuerst muss ich durch mein Buch: Linux-Unix-Systemnprogrammierung kommen.

Danach sollte ich ein besseres Verständnis haben.

[BinEinGast]

warum? alles was eine os-funktion kann, kann ein dienstprogramm auch

Eher andersrum ^^ alles was ein dienstprogramm kann sollt eine Api vom BS auch oder ^^ wobei man hier sehr wohl unterscheiden muss, auf welchen Standard man sich runner begibt (Posix, Distri )

so kann man das auch sehen. mir war zu diesem zeitpunkt nur nicht klar, warum die verwendung von dienstprogrammen schon durch die aufgabenstellung ausgeschlossen sein soll, da es nicht daran liegen kann, daß sie nicht mächtig genug sind. jetzt ist klar, daß du es wegen 'eklatanten sicherheitsproblemen' ausschließt, wobei mir noch immer nicht klar ist, warum die verwendung von programmaufrufen/os-funktionen sicherheitskritisch sein soll.

mal ein szenario für begriffsstutzige (wie u.a. mich): ich schreibe ein programm, das zu einem server eine verbindung aufbaut, sich vom eigenen os-kern die MAC eines beliebigen net-controllers geben läßt und eine APDU mit der MAC als inhalt an den server sendet.

ist deiner meinung nach der syscall zum erhalten der MAC kritisch oder ist es kritisch, daß die funktion zum abfragen überhaupt zur verfügung steht, weil z.b. viren, etc. damit unfug treiben könnten?



das betriebssystem stellt auch nur solche funktionien zur verfügung, die der 'nutzer' auch nutzen können soll.


und du willst programme schreiben die drueber hinausgehen ? dann solltest aber auch damit leben, dass dein programm nicht mehr portabel und plattformunabhaengig bleibt ....


es ging rein um den von dir angesprochenen sicherheitsaspekt



exec/system aufruf als solches immer mit sich bringt, egal was man da genau aufruft

nach genau denen frage ich dich ja



Wenn man die sache einmal macht ... ok
wenn man die infos aber 20 mal die sekunde braucht ....
und ich red ned um overhaed den das hilfsprogramm brauch, sondern overhead den dein programm braucht um den eigenen prozess fuers hilfsprogramm zu ueberlagern ...
zum besipiel ruf mal zigtausend mal gethostbyname auf, oder parse zigtausend mal den ausgabestream von nem exec ("nslookup irgendwas").

man kann sich natürlich immer eine situation konstruieren, in der eine bestimmte lösungsmöglichkeit ausscheidet. in der von dir oben beschriebenen gebe ich dir recht.

ich vertrete auch nicht die meinung, daß, wann immer man vor der entscheidung steht die ausgabe eines dienstprogrammes zu parsen oder eine os-funktion aufrufen, die erste methode die einzig wahre ist, sondern daß es vielmehr eine design-entscheidung ist, wie du selbst gesagt hast:



Ich behaupte nicht das scripts keine vorteile haben ... wenn ein script meine anforderungen erfuellt, ist es meist sogar die bessere variante, weil es eben weniger entwicklungszeit verbraucht hat, aber darum gehts hier wohl nicht oder ?




Das Osi Schichtmodell haett mir mein Informatiklehrer bei der Frage um die Ohren gehauen ^^

...



Im ernst, wenn du TCP/IP im speziellen falle UDP verwenden willst, solltest du dich an konventionen halten.

TCP/IP : UDP/IP war nur als beispielszenario gedacht



Im ernst, wenn du TCP/IP im speziellen falle UDP verwenden willst, solltest du dich an konventionen halten [...] nicht mal auf TCP/IP schicht [...]

zieh mal den kopf ein, sonst gibt's ärger vom pauker.

erklär mir doch bitte erst mal, was du unter TCP/IP-schicht verstehst. TCP ist, soweit ich weiß, transportschicht (schicht 4), IP netzwerkschicht (schicht 3). zugegeben, schichten 3 und 4 verschmelzen stark, aber dann kann ich durchaus eigene, auf schicht 2 (MAC-verwendende protokolle) neue protokolle aufsetzen, die die schicht 3/4 ausfüllen.



Und eine davon ist, das die MAC eben Implementationsdetail ist [...] TCP/IP frames verwenden und gleichzeitig MAC adressen auswerten

gleichzeit mit MACs und IP-packets zu arbeiten ist natürlich indiskutabel. wenn du aber selbst die schichten 3/4 implementieren willst, ist die MAC für dich selbst kein implementierungsdetail mehr.



schreibst du programme oder Tools zur systemverwaltung ^^ das ist nen unterschied, und zwar nen gewaltiger ^^

ich rede die ganze zeit nur von programmen, die im user-space operieren. ob die system-inis editieren oder über's netzwerk irgendwelche server konfigurieren, ist da doch (falls ich mich irre laut stop schreien) egal.
ich habe außerdem nicht unterschieden, ob das programm von root oder dem rest der welt aufgerufen werden kann.

ich glaube die ganze diskussion hängt daran, daß wir zu allgemein argumentieren. ein diskussion darüber, wann man scriptet statt zu coden, wann man os-funktionen, interrupt-routinen oder dienstprogramme verwendet und lauter so zeugs fände ich hingegen sinnvoll.



Konstant schon, aber das Starten des externen Executables ist Overhead und das Parsen des Outputs auch.

es stellt sich ja auch die frage, ob es nicht situationen gibt, in denen dieser overhead nicht trotzdem sinnvoll ist, oder nicht ins gewicht fällt, weil bla bla ...



Abgesehen davon ist das Parsen eines Programmoutputs, der nicht für maschinelle Weiterverarbeitung gedacht ist, also keinen definierten Konventionen folgt, immer eine problematische Sache. Thematik Screenscraping.

jup

[RHBaum]

ich glaube die ganze diskussion hängt daran, daß wir zu allgemein argumentieren. ein diskussion darüber, wann man scriptet statt zu coden, wann man os-funktionen, interrupt-routinen oder dienstprogramme verwendet und lauter so zeugs fände ich hingegen sinnvoll.

Richtig ^^

Der Threadersteller hatte gefragt, z.b. wie er mit C/C++ auf die Mac adresse einer eingebauten Netzwerkkarte kommt. Und noch andere informationen.

Und sich "beschwert" das eben diese Informationen nicht einheitlich zur verfuegung stehen ....

Und genau hier kolliediert er mit der Philosophie des Betriebssystemes. Ein Unix stellt dir eine Schnittselle / eine definierten umfang von Hilfsprogrammen / BS-API's zur verfuegung. Diese Standards (Posix SystemV) werden aber von unterschiedlichen Unixen (Linux, Linux distries) unterschiedlich erreicht ...
Also ist eine Mac Adresse z.b. ein Implementationsdetail ... in dem falle vom TCP/IP Stack. Einem Unix / Linux etc ist nicht vorgeschrieben, wie es die MAC adressen seiner karten zu verwalten hat, sondern nur die TCP/IP funktionen muessen gehen ^^ Und genau das ist das eigentliche philosophische Problem an der Sache ^^


wenn du aber selbst die schichten 3/4 implementieren willst, ist die MAC für dich selbst kein implementierungsdetail mehr.

Natuerlich nicht mehr ... aber das ist dann auch kein UNIX kompatibles problem mehr ^^ Du baust nen eigenes Protokoll an der Stelle, und das ist nicht mehr teil des Standards ... du greifst auf tiefere ebenen zu, die nicht mehr standardisiert sind.
Und deshalb meine Aussage, du kannst dann von Unix (Posix, SystemV) nicht mehr erwarten, die Informationen und functionalen einsprungpunkte zu einfach bekommen, die du zur implementation brauchst ... Im gegenteil, du musst damit rechnen dass deine Loesung nicht mehr unter jedem Unix / Linux laeuft, und du wahrscheinlich fuer jede Version wo es drauf laufen soll, vielleicht auch bei der selben distrie nur unterschiedliche versionsnummern, anpassungen vornehmen musst ....

Viele tools fuer die administration (dhcp, iptables, ipfwadm etc) greifen natuerlich weiter unten zu, sind aber auch kein bestandteil der standards ... es gibt durchaus z.b. noch unixe wo kein iptables laeuft ... und fuer den dhcpd und dhcp_client gibt es mehrere implementationen, die sich teilweise unnerschiedlich verhalten

Natuerlich ist dhcp (als protokoll) z.B. standardisiert, aber es ist kein bestandteil von SystemV oder Posix, und auch ned von TCP/IP


TCP ist, soweit ich weiß, transportschicht (schicht 4), IP netzwerkschicht (schicht 3).
Ich hoffe mein Lehrer sieht das nicht ^^ aber ich glaub der Standard TCP/IP -Stack deckt Schicht 3-5 sogar ab.

Ging darum das TCP/IP nix mit schicht 2 zu tun hat ...


warum die verwendung von dienstprogrammen schon durch die aufgabenstellung ausgeschlossen sein soll
Das es nicht alle programme gibt, schliess ich mal aus ... fuer alle hilfsprogramme die im standard sind, gibt es meist auch ne entsprechende API funktion / oder andersrum ...

Aber an nen richtiges binary hat man meist komplett andere Anforderungen wie an nem script.

Geschwindigkeit ist manchmal ein faktor, wird aber meist viel zu hoch bewertet .... scripte sind in den meisten faellen schnell genug

Sicherheit ist ein thema ... nen script hat immer sicherheitsluecken. bei einem Script kann und werde ich auch nur erwarten, das es maximal so sicher ist wie die verwendeten hilfstools. wenn mir wer da nen trojaner unnergeschoben hat, bin ich mitm script machtlos ...
bei nem binary erwart ich das nicht aufm ersten blick ^^
das mir einer meine systemlibs verbiegt, ist viel unwahrscheinlicher, wenn auch nicht ausgeschlossen. Aber bei so nem komprimittierten system ist gar nix mehr sicher ....

wenn ich externe tools in nem binary verwende kommt meist frueher oder spaeter der wunsch auf, das konfigurierbar zu machen ... beispielsweisse ob ich grep oder egrep irgendwo verwende ... diese einstellung und die Ablage der Info muesst ich auch absichern ... sonst schiebt mir da wer sonstwas unter ....

suchpfade, userid ... mit welchen rechten laeuft das tool, wie stehen die umgebungsvariablen, das hat auswirkungen auf den start des tools .... bei nem script acht ich als admin expliziet drauf, bei nem binary erwart ich einfach nicht das ich darauf achten muss ....

und last but not least ... verhalten bei out of memory / buffer-stack overflow / system haengt.
Bei nem C programm kann ich zumindest darauf achten, das in solchen faellen nichts sicherheitskritisches passiert .... bei nem exec aufruf verlier ich da total die kontrolle, da kann ich kaum mehr was garantieren .... Wenn in dem falle mein exec zurueckkehrt und die speicherbereiche zurueckgeschrieben werden ist undefiniert was da drinne steht, das kann sich nen angreifer zunutze machen ....

Bei nem Script ist die gefahr allgegenwaertig, nen script muss ich halt von aussen absichern ....
nen binary sollt auch in ner unsicheren umgebung sicher sein ....
Scripts laufen auch meist nicht wirklich lange .... su tun was, gut ist ^^
nen programm laeuft teilweisse ueber stunden ... wenn es ne oberflaeche hat, macht der User was damit ....
In der Zeit kann sich der systemzustand aendern, da sollt das binary immer noch sicher sein und damit klarkommen, bei nem script erwart ich das nich unbedingt ...

Ciao ...