nicht angemeldet
DAU User Config-file
JürgenBhallo
Schaut euch mal dieses Konfig File an. Da lachen doch die Hühner…
# for localhost
$PASSWORD = "773af4ce1783ad48d447cf55ecc509340a43fc37213c6686f37f88ebb22469147b1c68ca178cde6292e3524b0f5aabf165b1a4d0da606519e640653e4a350216";
@LIMIT_FILETYPE = qw( html svg txt css js );
@LIMIT_DIR = qw( /pub /images /css /js );
@LIMIT_WRITE_DIR = qw( /pub /images /js /css );
$ROOT_DIR = "..";
$HTTP_BASE_PATH = "/html";
$REDIRECT = 'http://localhost/html/editor/kissedit.html';
$FILESYSENCODING = "CP1252"; #betrifft Dateinamen auf modernen Windows
#$FILESYSENCODING = "iso-8859-1"; #betrifft Dateinamen auf UNIXoiden
Das ist ein pm, das einfach so eingebunden wird.
require "kissedit_config.pm";
Hey but it works on my computer
Also gings nur um mich, könnt ich das ja stehen lassen.
Aber ich erwarte, dass User von unbekannter technischer Intelligenz diese Konfiguration nun ja konfigurieren.
Und da sind wir bei der Frage, was ist
- das DAU konformste INIFILE Format
- mit nur moderatem technischem Aufwand.
-
Tach!
Aber ich erwarte, dass User von unbekannter technischer Intelligenz diese Konfiguration nun ja konfigurieren.
Das erwarte ich nicht. Ein paar Kenntnisse sollte ein Betreiber komplexer Systeme schon mitbringen.
Und da sind wir bei der Frage, was ist
- das DAU konformste INIFILE Format
- mit nur moderatem technischem Aufwand.
Ich würde das nicht so sehr am Format festmachen, sondern an der allgemeinen Lesbarkeit. Für mich spielt weniger eine Rolle, ob da die einigermaßen einfache INI-Syntax oder das Anlegen von ein paar Variablen/Arrays einer Programmiersprache in der Datei steht. Das System muss erkennbar sein, wie die Werte hinzuzufügen oder zu ändern sind. Kommentare und Beispiele sind dazu sehr wichtig.
dedlfix.
-
hallo
Tach!
Aber ich erwarte, dass User von unbekannter technischer Intelligenz diese Konfiguration nun ja konfigurieren.
Das erwarte ich nicht. Ein paar Kenntnisse sollte ein Betreiber komplexer Systeme schon mitbringen.
Und da sind wir bei der Frage, was ist
- das DAU konformste INIFILE Format
- mit nur moderatem technischem Aufwand.
Ich würde das nicht so sehr am Format festmachen, sondern an der allgemeinen Lesbarkeit. Für mich spielt weniger eine Rolle, ob da die einigermaßen einfache INI-Syntax oder das Anlegen von ein paar Variablen/Arrays einer Programmiersprache in der Datei steht. Das System muss erkennbar sein, wie die Werte hinzuzufügen oder zu ändern sind. Kommentare und Beispiele sind dazu sehr wichtig.
Aber du musst doch zugeben, dass es ein Unterschied ist
- Ob eine Konfigurationsanweisung nicht verstanden/interpretiert wird.
- Oder ob sie zu einem Fehler führt, der nach lästigen Folgehandlungen ruft, wie etwa error.txt zu konsultieren.
-
Tach!
Aber du musst doch zugeben, dass es ein Unterschied ist
- Ob eine Konfigurationsanweisung nicht verstanden/interpretiert wird.
- Oder ob sie zu einem Fehler führt, der nach lästigen Folgehandlungen ruft, wie etwa error.txt zu konsultieren.
Nö, muss ich nicht. Ich wüsste nicht, was das kleinere Übel wäre, eine Änderung, die keine Auswirkung zeigt oder ein Fehler, der als Folge der Änderung deutlich zu sehen ist, und damit zeigt, dass die Änderung so nicht richtig war. Die eigentliche Frage ist, wie einfach man an Hilfe kommt, wie das eigentlich gewollte korrekt zu konfigurieren ist.
dedlfix.
-
hallo
Tach!
Aber du musst doch zugeben, dass es ein Unterschied ist
- Ob eine Konfigurationsanweisung nicht verstanden/interpretiert wird.
- Oder ob sie zu einem Fehler führt, der nach lästigen Folgehandlungen ruft, wie etwa error.txt zu konsultieren.
Nö, muss ich nicht. Ich wüsste nicht, was das kleinere Übel wäre, eine Änderung, die keine Auswirkung zeigt oder ein Fehler, der als Folge der Änderung deutlich zu sehen ist, und damit zeigt, dass die Änderung so nicht richtig war. Die eigentliche Frage ist, wie einfach man an Hilfe kommt, wie das eigentlich gewollte korrekt zu konfigurieren ist.
Vorgesehen (derzeit implementiert) ist, dass ein Aufruf ohne irgend ein action Paramter die Anleitung zur Konfiguration ausgibt. Dabei werden derzeit geltende Werte mit angezeigt. Der user hat also Kenntnis darüber, ob seine Angaben interpretiert wurden. Insbesondere wird ein neuer Paswort-Hash aufgrund eines übermittelten Passwort Strings ausgegeben.
Wenn ich aber in der derzeitigen .pm einen Syntaxfehler erzeuge, bekommt der User im Browser nur einen 500er.
vielleicht sollte ich das mit einem try .. catch um das require mindestens abfangen.
-
oder das Anlegen von ein paar Variablen/Arrays einer Programmiersprache in der Datei steht
Genau das ist ein Sicherheitsproblem: So lässt sich nämlich jeder beliebige Code einschleusen.
MfG
-
hallo
oder das Anlegen von ein paar Variablen/Arrays einer Programmiersprache in der Datei steht
Genau das ist ein Sicherheitsproblem: So lässt sich nämlich jeder beliebige Code einschleusen.
Wenn 'einschleussen' möglich ist, kann aber bei einem INI-File auch einfach das PASSWORD_HASH auf einen Wert gestellt werden, der übernahme möglich macht. Der Angreifer kann sich dann im weiteren den Editor_wirkbereich auf auf .pl und .pm Dateien ausdehnen, und Scripte direkt via Editor schreiben.
Wir wollen primär erreichen, das unbedarfte User keine Fehler erzeugen, die zu esotorischen Fehlern führen.
Sicherheit erreichen wir dann dadurch, dass die Files auf readonly gestellt werden.
-
Nun,
require,useoderdokompilieren. Dateien die so eingebunden werden, sind als Public Schnittstelle völlig ungeeignet, denn damit wird auch Schadcode kompiliert!So wirst Du doch Deinen Benutzern nicht erlauben, daß sie ihren eigenen Code in Deine Anwendung einbauen dürfen!?
Grausige Vorstellung. Tu es nicht.
-
-
Tach!
oder das Anlegen von ein paar Variablen/Arrays einer Programmiersprache in der Datei steht
Genau das ist ein Sicherheitsproblem: So lässt sich nämlich jeder beliebige Code einschleusen.
Wir reden hier von interpretierenden Sprachen, bei denen der Code des Projekts in lesbarer Form vorliegt. Wer in die Konfigurationsdatei Code einfügen kann, kann das auch in jede beliebige andere Datei des Projekts. Das Problem besteht nicht darin, dass man Code in diese Datei einfügen könnte, sondern wenn Nicht-Administratoren an irgendeiner beliebigen Stelle des gesamten Projektcodes Manipulationen vornehmen können.
dedlfix.
-
-
# for localhost $PASSWORD = "773af4ce1 ... 653e4a350216"; @LIMIT_FILETYPE = qw( html svg txt css js ); @LIMIT_DIR = qw( /pub /images /css /js ); @LIMIT_WRITE_DIR = qw( /pub /images /js /css ); $ROOT_DIR = ".."; $HTTP_BASE_PATH = "/html"; $REDIRECT = 'http://localhost/html/editor/kissedit.html'; $FILESYSENCODING = "CP1252"; #betrifft Dateinamen auf modernen Windows #$FILESYSENCODING = "iso-8859-1"; #betrifft Dateinamen auf UNIXoidenHm. Klar. Perl in alter "Schönheit".
Aber ich erwarte, dass User von unbekannter technischer Intelligenz diese Konfiguration nun ja konfigurieren.
Das gute alte ini-Format. Muss eben eine Routine her, welche die ini liest, und in die "kissedit_config.pm" übersetzt. Die kann und sollte dann auch Fehler abfangen.
Irgendwo hab ich was von Browser gelesen. Ist da ein Grund, den Benutzer kein HTML-Formular ausfüllen zu lassen? Oder geht es hier quasi um den Setup, also um die Einstellungen des Verwalters einer Webanwendung, die lokal erzeugt und dann via ftps, scp oder dergleichen auf den Server übertragen werden - dann hielte ich obiges für tragbar.
Sonstige Kritik:
$FILESYSENCODING = "iso-8859-1"; #betrifft Dateinamen auf UNIXoidenIch bin mir nicht sicher, was damit gemeint ist. Aber bei allem, was im Ergebnis meiner Überlegungen in Frage kommt, würde ich auf halbwegs aktuellen Systemen "utf-8" eintragen.
$PASSWORD = "773af4ce1 ... 653e4a350216";Hehe. Das sieht nicht gut aus. Perl kann bcrypt. Ich schreib gern was, dann kann Perl auch
password_hash(),password_verify()undpassword_needs_rehash().-
hallo
# for localhost $PASSWORD = "773af4ce1783ad48d447cf55ecc509340a43fc37213c6686f37f88ebb22469147b1c68ca178cde6292e3524b0f5aabf165b1a4d0da606519e640653e4a350216"; @LIMIT_FILETYPE = qw( html svg txt css js ); @LIMIT_DIR = qw( /pub /images /css /js ); @LIMIT_WRITE_DIR = qw( /pub /images /js /css ); $ROOT_DIR = ".."; $HTTP_BASE_PATH = "/html"; $REDIRECT = 'http://localhost/html/editor/kissedit.html'; $FILESYSENCODING = "CP1252"; #betrifft Dateinamen auf modernen Windows #$FILESYSENCODING = "iso-8859-1"; #betrifft Dateinamen auf UNIXoidenHm. Klar. Perl in alter "Schönheit".
Abgesehen von our( ... ) Deklarationen im Hauptscrypt.
Aber ich erwarte, dass User von unbekannter technischer Intelligenz diese Konfiguration nun ja konfigurieren.
ini-Format. Muss eben eine Routine her, welche die ini liest, und in die "kissedit_config.pm" übersetzt.
Wäre zu evaluieren.
Irgendwo hab ich was von Browser gelesen. Ist da ein Grund, den Benutzer kein HTML-Formular ausfüllen zu lassen? Geht es hier quasi um den Setup, also um die Einstellungen des Verwalters einer Webanwendung, dann halte ich es für tragbar.
Ich glaube du magst chicken-egg probleme. Nein, für diese Konfig darf's kein Webinterface geben. Der Browser gibt lediglich die wirksame konfiguration aus zwecks Überprüfung.
Sonstige Kritik:
$FILESYSENCODING = "iso-8859-1Ich bin mir nicht sicher, was damit gemeint ist. Aber bei allem, was im Ergebnis meiner Überlegungen in Frage kommt, würde ich auf halbwegs aktuellen Systemen "utf-8" eintragen.
Da gibts einen langen thread dazu https://forum.selfhtml.org/self/2018/oct/26/perl-filesystem-encoding-erkennen/1735181#m1735181
$PASSWORD = "773af4ce1 ... 653e4a350216";Hehe. Das sieht nicht gut aus. Perl kann bcrypt. Ich schreib gern was, dann kann Perl auch
password_hash(),password_verify()undpassword_needs_rehash().lies $PASSHASH sha2 gesalzen.
-
Ich glaube du magst chicken-egg probleme.
Ich kenne die Lösung. Wenn man das Huhn-Ei-Problem ein bis zwei Milliarden Jahre lang zurück itieriert und dabei die Veränderungen der DNS be(ob)achtet steht da: Vor dem Urschleim gab es nur tote Materie. Die andere Lösung unter stärkerer Begrenzung auf "Huhn" und Beachtung der Erbgutveränderung durch den Zeugungsakt ist ebenfalls eindeutig: Das Ei war zuerst da. Es wurde nämlich durch ein Tier gelegt, auf welches die engere Definition von "Huhn" nicht zutrifft.
Charles Darwin (1809 - 1889) hat das Huhn-Ei-Problem also schon vor rund 150 Jahren gelöst.
-
-
# for localhost $PASSWORD = "773af4ce1 ... 653e4a350216"; @LIMIT_FILETYPE = qw( html svg txt css js ); @LIMIT_DIR = qw( /pub /images /css /js ); @LIMIT_WRITE_DIR = qw( /pub /images /js /css ); $ROOT_DIR = ".."; $HTTP_BASE_PATH = "/html"; $REDIRECT = 'http://localhost/html/editor/kissedit.html'; $FILESYSENCODING = "CP1252"; #betrifft Dateinamen auf modernen Windows #$FILESYSENCODING = "iso-8859-1"; #betrifft Dateinamen auf UNIXoidenHm. Klar. Perl in alter "Schönheit".
Es ist alles Andere als schön: Denn es müllt den aktuellen Namespace mit globalen Variablen zu. Wenn man es scho so machen will, dann besser so, daß die mit
dooderrequireeingebundene Datei eine Referenz auf einen Hash liefert:{ vname => 'Mikosch', name => 'Theodorakikus', # usw.. }und so kann man alles zusammen auch besser prüfen. MfG
-
-
Hi,
eine Konfigurationsdatei muss unabhängig von der Programmiersprache sein. Eine .ini liefert E/A/V (Entity Attribute Value) und auch das lässt sich tiefer schachteln.
a=voderx:yreicht ja vielleicht auch schon, das lässt sich prima parsen (gerade eben mit Perl). Und auch JSON gänge, aber ich will hier keine Empfehlung abgeben. Außer den Hinweis noch, daß solche textbasierten Dateichen u.U. Flaschenhälser sein können, insbesondere wenn es viele sind oder in den MB Bereich hineinwachsen.Abhelfe schafft da nur ein zweckmäßiges Deployment.
MfG
-
Hallo Beat,
wenn du eine DAU-sichere Configdatei willst, halte den DAU vom Config fern. Schreib ein Script oder Programm, das die Wünsche des Users im Dialog ermittelt und die Configdatei erstellt.
Gruß
Jürgen-
hallo
Hallo Beat,
wenn du eine DAU-sichere Configdatei willst, halte den DAU vom Config fern. Schreib ein Script oder Programm, das die Wünsche des Users im Dialog ermittelt und die Configdatei erstellt.
OK, dann brauchen wir eine Konfiguration zu jenem Admin Script! ;)))
Mein Vorschlag für eine sichere Config:
SET_PASSWORD_HASH 773af4ce1783ad48d447cf55ecc509340a43fc37213c6686f37f88ebb22469147b1c68ca178cde6292e3524b0f5aabf165b1a4d0da606519e640653e4a350216 SET_ROOT_DIR .. ADD_FILETYPE html ADD_FILETYPE svg ADD_FILETYPE txt ADD_FILETYPE js ADD_DIR /pub ADD_DIR /images ADD_DIR /css ADD_DIR /js ADD_WRITE_DIR /pub SET_HTTP_BASE_PATH /html SET_REDIRECT http://localhost/html/editor/kissedit.html SET_FILESYSENCODING CP1252-
Hallo Beat,
und wie reagiert dein System auf falsche Eingaben?
ADD_FILETYPE cpp
Woher kennt der DAU deine Syntax?
Gruß
Jürgen-
hallo
Hallo Beat,
und wie reagiert dein System auf falsche Eingaben?
open(my $c, "<", $CONFIG_FILE ) or die $!; while(<$c>){ $_ =~ m{^SET_PASSWORD_HASH \s+ (\S+) }x and $PASSWORD_HASH = $1 and next; $_ =~ m{^SET_ROOT_DIR \s+ (\S+) }x and $ROOT_DIR = $1 and next; $_ =~ m{^SET_HTTP_BASE_PATH \s+ (\S+) }x and $HTTP_BASE_PATH = $1 and next; $_ =~ m{^SET_REDIRECT \s+ (\S+) }x and $REDIRECT = $1 and next; $_ =~ m{^SET_FILESYSENCODING \s+ (\S+) }x and $FILESYSENCODING = $1 and next; $_ =~ m{^ADD_FILETYPE \s+ (\S+) }x and push( @LIMIT_FILETYPE, $1) and next; $_ =~ m{^ADD_DIR \s+ (\S+) }x and push( @LIMIT_DIR, $1) and next; $_ =~ m{^ADD_WRITE_DIR \s+ (\S+) }x and push( @LIMIT_WRITE_DIR, $1) and next; } close $c;Nicht registrierte Parameter werden ignoriert. Wenn unsinnige Direktories angegeben werden, wird das an anderer Stelle zu Fehlern führen.
ADD_FILETYPE cpp
Woher kennt der DAU deine Syntax?
Die wird dokumentiert, wenn man kissedit.pl ohne action Parameter aufruft.
-
hallo
ADD_FILETYPE cpp
Woher kennt der DAU deine Syntax?
Die wird dokumentiert, wenn man kissedit.pl ohne action Parameter aufruft.
Da kannst Du auch gleich ein Konfigurations-Editor-Backend für den Browser anbieten. Mach ein schönes Formular mit Erklärungen zu jedem Eingabefeld und alles wird gut.
MfG
-
hallo
hallo
ADD_FILETYPE cpp
Woher kennt der DAU deine Syntax?
Die wird dokumentiert, wenn man kissedit.pl ohne action Parameter aufruft.
Da kannst Du auch gleich ein Konfigurations-Editor-Backend für den Browser anbieten. Mach ein schönes Formular mit Erklärungen zu jedem Eingabefeld und alles wird gut.
Gut, und wie schreibe ich die Configuration zu diesem Konfigurationseditor?
Tststs... Warum nur tappt ihr alle in die gleiche irrige Annahme, die Lösung sei noch mehr Webformulare?
-
hallo
Gut, und wie schreibe ich die Configuration zu diesem Konfigurationseditor?
Auf CPAN gibt es ungezählte Module für Konfigurationsdateien. Z.B.
Config::TinyWas Deine Anwendung betrifft, überlege Dir eine Policy hinsichtlich public und admin Bereichen (Realms). Diese Policy kann bis in die Konfiguration hineinreichen derart, daß es Parameter gibt die nur administrative festgelegt sind und Parameter die ein Benutzer festlegen bzw. ändern darf.
MfG
-
hallo
Auf CPAN gibt es ungezählte Module für Konfigurationsdateien. Z.B.
Config::TinySag mir lieber, was schlecht ist an der letzten Version.
Was Deine Anwendung betrifft, überlege Dir eine Policy hinsichtlich public und admin Bereichen (Realms). Diese Policy kann bis in die Konfiguration hineinreichen derart, daß es Parameter gibt die nur administrative festgelegt sind und Parameter die ein Benutzer festlegen bzw. ändern darf.
Die Policy ist einfach: Entweder das Passwort ist richtig oder falsch. Ein Admin zeichnet sich auch dadurch aus, dass er einen FTP Zugang oder andere Filetransfer-Möglichkeiten hat, die ich nicht kennen muss.
-
hallo
Auf CPAN gibt es ungezählte Module für Konfigurationsdateien. Z.B.
Config::TinySag mir lieber, was schlecht ist an der letzten Version.
Finde es selbst heraus.
-
-
-
Hallo Beat,
Gut, und wie schreibe ich die Configuration zu diesem Konfigurationseditor?
egal, die ist nur für dich.
Tststs... Warum nur tappt ihr alle in die gleiche irrige Annahme, die Lösung sei noch mehr Webformulare?
Warum tappst du in die irrige Annahme, eine DAU-sichere Configdatei hinzukriegen? Der DAU vergisst, die Config-Datei nach dem Editieren hochzuladen.
Vielleicht musst du auch mal festlegen, was für dich ein DAU ist.
Gruß
Jürgen-
hallo
Hallo Beat,
Gut, und wie schreibe ich die Configuration zu diesem Konfigurationseditor?
egal, die ist nur für dich.
Wenns nur um mich ginge, bliebe ich bei der Perl-Modul Variante.
Tststs... Warum nur tappt ihr alle in die gleiche irrige Annahme, die Lösung sei noch mehr Webformulare?
Warum tappst du in die irrige Annahme, eine DAU-sichere Configdatei hinzukriegen? Der DAU vergisst, die Config-Datei nach dem Editieren hochzuladen.
Von einem DAU, der seine Webseite betreibt, erwarte ich, dass er Dinge wie Editor und FTP versteht.
Ich erwarte nicht dass er Perl-Syntax versteht.
Das ist der Unterschied
-
Ich erwarte nicht dass er Perl-Syntax versteht.
Was Du immer erwarten kannst und auch erwarten solltest, ist der Fakt, daß ein DAU alles kaputtmachen kann -- Mit oder ohne Perl-Syntax Kenntissen. Davon musst Du ausgehen!
MfG
-
-
-
-
-
-
-
-