C Startdatei

Sojus

Sojus

Aktives Mitglied
Thread Starter
Dabei seit
30.05.2006
Beiträge
144
Reaktionspunkte
3
Hallo

Ich muss für mein aktuelles Projekt ein kleines C Programm (Linux) schreiben. Dieses Programm wird dann von einem Perl-Script ausgeführt.

Das C-Programm soll nun herausfinden von welchem PerlScript es aufgerufen wurde. Ich bräuchte die URL zu der Datei.

Ich habe mich schon durch die C "API" gekämpft, die über das internet verteilt ist und bin nicht fündig geworden.

Ich bin nicht sicher, ob das überhaupt möglich ist. Wenn jemand eine idee hat währe ich froh.

mfg
 
Lass das C Programm die History der Shell auswerten, falls das Perl-Script in Terminal gestartet wurde. (Scherz :) )

Ich bräuchte die URL zu der Datei.
Im normalen Sprachgebrauch spricht man hier von Path oder auf Deutsch Pfad. :p Eiei was haben sie Euch in der Schule erzählt.
 
Dafür gibt es doch in C für mein argc und argv um die Aufrufparameter auslesen zu können! Startest Du nun aus perl heraus das Programm mit einem Parameter der das Aufrufskript benennt, hast Du alles was Du brauchst:

# mein Perl-Script myperl.pl
.
.
system("/usr/local/bin/deincprogramm -src myperl.pl");


Mein Perl ist etwas eingerostet, obiges also nur Pseudocode ( ich kenn den Aufruf für Systemprogramme in Perl nichtmehr). In jedem Fall kommst Du so zu Deinem Aufrufenden Programm! Das ist Standard-C!
 
Dafür gibt es doch in C für mein argc und argv um die Aufrufparameter auslesen zu können! Startest Du nun aus perl heraus das Programm mit einem Parameter der das Aufrufskript benennt, hast Du alles was Du brauchst:

# mein Perl-Script myperl.pl
.
.
system("/usr/local/bin/deincprogramm -src myperl.pl");


Mein Perl ist etwas eingerostet, obiges also nur Pseudocode ( ich kenn den Aufruf für Systemprogramme in Perl nichtmehr). In jedem Fall kommst Du so zu Deinem Aufrufenden Programm! Das ist Standard-C!

Danke für die idee. leider geht das so nicht.

Das C Programm ist dafür da, dass es nur authorisierten Scripts das Passwort für eine Oracle DB gibt. Es soll erkennen welche inode nummer die Scriptdatei hat von dem es aufegrufen wurde. Wenn die Inode Nummer korrekt ist gibt das script das DB Passwort zurück.

Mit Startparameter, währe das ziemlich unsicher. Währe es vielleicht möglich die informationen über den Perlprozess zu beziehen?

mfg
 
Die Geschichte mit dem inode ist mehr als Murks: inodes werden unter Linux nicht notwendigerweise vom Dateisystem (ReiserFS) verwendet. Sie sind an genau einen Eintrag im Dateisystem gebunden; jedesmal wenn Du das Aufruferscript installierst, verschiebst oder kopierst müsstest Du das C-Programm neu kompilieren.

Mir scheint, Du hast da eine ziemlich holprige Sache vor, die vielleicht nicht so toll funktioniert: Du kannst mit getppid() die pid des aufrufenden Prozesses finden und mit dieser den vollen Pfad zur Aufruferdatei und alles mögliche andere aus dem /proc-Verzeichnis herauslesen, zur Not sogar den inode. Siehe Example 28-1. Finding the process associated with a PID. Das klappt aber nur unter Linux.

Wenn Du trotzdem so ein Programm schreiben willst, das nur bei stimmigen Rahmenbedingungen laufen soll und die Legitimität seines Aufrufer-Prozesses/Scriptes kontrolliert, dann implementier einen ganz einfachen Zertifikat-Algorithmus:

- Erstell einmalig einen geheimen Schlüssel und ein nicht zugängliches Tool, das ein Zertifikat ausstellt.

- Wenn ein Script zertifiziert werden soll, erhält das Zertifikataussteller-Tool wesentliche Merkmale des Scripts (SHA1 Prüfsumme der finalen Version, erlaubte uids, guid), verschlüsselt diese und gibt eine kleine Datei mit der Chiffre zurück, das Zertifikat.

- Das Script wird zusammen mit dem Zertifikat auf der Client-Maschine abgelegt.

- Wenn das Script laufen will, teilt es dem C-Programm (per Kommandozeilenargument) mit, wo das Zertifikat liegt.

- Das C-Programm entschlüsselt das Zertifikat, stellt wie oben beschrieben aus /proc fest wo das Aufruferscript liegt, bestimmt die wesentlichen Merkmale mithilfe von /proc selbst und vergleicht diese mit denen, die es aus dem Zertifikat entschlüsselt hat.

Zum Verschlüsseln würde sich z. B. Blowfish anbieten, SHA1-Sourcen gibts auch... denk Dir was aus ;)
 
Zuletzt bearbeitet:
Kannst du das nicht einfach irgendwie über passende Ausführrechte für das C Programm lösen. Ich würde das gar nicht innerhalb des Programms regeln wenn möglich. Die Geschichte mit dem Inode klingt jetzt schon irgendwie nach... äh... Pfusch. ;) :D
 
Vielen dank fuer die anregungen. Werde das mal meinem chefe vorschlagen, der hat bist jetzt nur "mach mit inode" gsagt. Mal schaune..


mfg
 
Was wollt Ihr denn genau erreichen? Hart gecodete Passwörter hören sich nicht gerade professionell an... :-/
 
Zuletzt bearbeitet:
Also es geht um ein Passwortverwaltungsprogramm. Darin werden Passwörter für Datenbanken, Server etc. verschlüsselt gespeichert. Fuer das Tool gibt es User, Gruppen, Organisationseinheiten über die man rechte für die jeweiligen Passwörter vergeben kann (diese Abteilung darf das Root PW für diesen Server lesen). Das ganze funktioniert recht gut.

Als zusatzfunktion sollen sich Scripte über dieses Tool Passwörter für Datenbankuser holen. Jetzt suche ich nach einer Authentifizierungsmethode. Dazu wollte ich eine zusätzliche Tabelle haben in der die Inode nummer der jeweiligen Scripte steht. Ueber das C Programm wird dan geprueft ob das ausführende Script in dieser Tabelle ist.

mfg
 
Zum Thema ist alles gesagt worden, das wiederhol ich also mal nicht. Die Sicherheit der Verschlüsselung endet in dem Moment wo die Kennwörter an Skripte übergeben werden, ab hier sind sie genauso sicher/unsicher wie Klartext-Paßwörter die irgendwo außerhalb des Document-Root stehen.


Egal ob Apache oder ein J2EE-Container, alle bringen zur Zugriffsverwaltung entprechende Anbindungen und tools mit um Zugriffe gegen PAM-Module abzusichern. Im Falle eines firmenweiten Intranets ist ein LDAP eine adäquate Lösung. Die Sicherheit durch ein compiliertes Programm endet eben ab dem Moment wo ein textlesbares Skript den Ablauf übernimmt.
 
Recht hat wegus!

Wenn es trotzdem sein muss, lass diesen inode-Murks und mach was mit zertifizierten Fingerprints. Ist ganz simpel (- es reicht ja schon die 20 Byte vom SHA1 zu verschlüsseln -) und sichert vor allem, dass niemand ein Script durch Schadcode ersetzt. Du kannst Dir externe Tabellen/Neukompilieren sparen, weil die Zertifikate fälschungssicher sind, da der key ebenfalls im C-Tool verbacken ist. Ausserdem ist diese Methode weniger abhängig vom Betriebssystem.

Wenn Du es richtig ernsthaft machen willst, arbeite mit "richtigen" digitalen Signaturen. Nicht umsonst arbeiten signierte Java-JARs und .NET-Anwendungen genauso.
 
Zuletzt bearbeitet:
Zurück
Oben Unten