Passwörter und OpenSource?

[makko]

Ich weiss, das gehört hier wohl nicht so richtig rein, aber ich weiss das hier kompetente leute sind die mir da weiterhelfen können

also folgendes, im moment arbeite ich mit nem kumpel zusammen an nem kleinen privaten software projekt, dabei wird unter anderem auch eine verbindung zu einem mysql server aufgenommen.

da jetzt aber in dem programm bibliotheken verwendet werden die unter der GPL liegen, müssen wir den gesamten quelltext offenlegen, aber was machen wir mit dem passwort für den mysql server? das soll ja nun nicht jedem bekannt sein

vielen dank im vorraus, makko

[mauser]

hi,

das musst du natürlich nicht offenlegen.. Dort trägt ja auch jeder sein eigenes Passwort ein.
mfg
mauser

[makko]

ja und wo positioniert man das passwort dann so source-technisch? :]

[mauser]

hi,

in einer Konfigurationsdatei, am besten irgendwo in /etc. Dort schreibt man dann als Passwort *irgendwas* rein (oder man lässt es leer). Der User tauscht dann *irgendwas* mit seinem eigenen Passwort aus. Oder wollt ihr das alle User des Programms eine einzige DB nutzen ????
mfg
mauser

[rahab]

Hey makko!

Kann sein dass ich mich jetzt schwer irre, aber wenn du nur bestimmte Bibliotheken einbindest, aus denen du z.B. Funktionen aufrufst, heißt das nicht gleich, dass du deinen ganzen Code unter die GPL stellen offen legen must.
IIRC gilt das nur dann, wenn du Code der unter der GPL steht weiter/wiederverwendest.
Wenn du z.B. in ein C-Programm GPL-Code einkompilierst ist das der Fall.
Wenn du aber z.B. eine Webanwendung schreibst und du dafür irgendeine AJAX-Library einbindest die unter der GPL steht, heißt das nicht gleich, dass das ganze Produkt dann unter der GPL steht, sondern nur dass man eben diese Library zugänglich machen muss.

Oder hab ich da was missverstanden ??

Cheers

[makko]

alsooo:

@mauser:
ja alle benutzer sollen dieselbe datenbank schreiben, sie haben zudem ein eigenes user passwort, aber die speicherung von dem ding is ja kein problem
nur aben das passwort um in die datenbank zu schreiben ist ja für alle gleich, muss im programm drin sein, aber eben nicht offen liegen

@rahab:
oha das weiss ich jetzt nicht genau, ich kanns ja etwas genauer beschreiben,
wir nutzen eine opensource bibliothek mit funktionen zum auslesen von id3 tags und diese steht unter der GPL
wenn wir diesen source nun einbinden und damit ja wiederverwenden, müssen wir das ja offenlegen, oder?
und andererseits, mal angenommen wir wollten absichtlich unser programm als opensource anbieten, wie ginge man in dem fall vor?

danke für das rege interesse, grüße, makko

Edit: achja und eine bibliothek zum lesen/schreiben von XML dateien is auch drin ;D

[ToPeG]

Mit GPL und Biblioteken ist das so eine Sache. Wenn du Eine Lib fest linkst oder dynamisch linkst und die Headerdateien nimmst, die unter der GPL stehen ist die Sache eindeutig. Wenn du das Programm veröffendlichst, mußt du es unter der GPL machen, da ja auch die Lib und die Headerdateien unter der GPL stehen. Wenn du aber die Headerdateien selber schreibst und einbindest, allso die unter der GPL stehende Biblithek dynamisch linkst und nur über die "öffendlichen" Schnittstellen ansprichst und keinen Code verwendest dann muß das Programm nicht unter der GPL stehen, da keine Codteile aus unter GPL stehender Software übernommen wurde. (wobei das für einige ein wirklicher Steitpunkt ist.)
Wenn du aber nun einen Warpper schreibst, allso eine Lib, die eine andere kaplset, welche unter der GPL steht, so mußt du sie unter der GPL veröffendlichen, kannst aber die Headerdateien z.B unter die LGPL stellen und in eine Closed Source Progamm ohne einen Rechtsverstoß einbinden. (dabei ist auch zu beachten, daß die Header-dateien nachweislich keinerlei GPL-Code enthalten dürfen)

Was das auslagern von Passwörtern, oder andere Accountdaten oder Einstellungen betrifft, so gibt es im allgemeinen drei Orte, wo ein Programm die Configdateien suchen sollte.
1. Im Homeverzeichnis des Users unter dessen Rechten das Programm läuft (am besten sollte die ConfigDatei, ungefähr so lauten ".<programmname>.conf" oder einfach ".<programmname>" bei komplexen Konfigrationen emfielt es nicht auch einen eigenen Ordner an zu legen in dem die nötigen Dateien abgelegt werden.)
2. Im verzeichnis "/etc" entwerder in einem Ordner unter dem Programmnamen, oder einer Datei mit dem Programmnamen.
3. unter /usr/share/<programmname>/
Zuderst wird im Homeverzeichnis gesuchet und dann im "/etc"-Verzeichnis. zuetzt unter "/usr/share/<programmname>/" Ist an keinem der drei Orte eine Configurationsdatei vorhanden empfielt es ich im Homeverzeichnis des aktuellen Beutzers eine an zu legen und im Ideralfall darauf hin zu weisen (log, Terminalausgabe, etc.)

[makko]

ok das mit der kapselung hat mir schonmal geholfen, danke soweit

zu den passwörtern nochmal,

das programm schreibt via sql daten in eine datenbank, dazu benötigt das programm das passwort um schreibzugriff auf die datenbank zu erhalten

die benutzer haben mit diesem passwort nichts zu tun und sie sollen auch nicht selbstständig auf die datenbank zugreifen können, eben nur durch das programm, damit niemand da schmu reinschreiben kann ;D

deshalb fallen speicherorte weg, denn das passwort soll irgendwie im programm sein, aber nicht sichtbar im source und schon garnicht im kompilierten programm.

eventuell die ganze db server verbindungs routine in eine fertig kompilierte bibliothek auslagern?

[mauser]

hi,

du erlaubst also beliebig vielen Usern einen Schreibzugriff auf deine Datenbank ? Dann nimm doch gleich das Passwort raus ! Allerdings halte ich das nicht gerade für eine gute Idee, da lässt sich doch sehr viel Unfug mit betreiben... Ich würde da noch ein Layer zwsichenhängen, um eine Kontrolle darüber zu haben was in die DB darf und was nicht.
mfg
mauser

[makko]

das soll ja das programm übernehmen

das programm sammelt die daten und fügt sie so ein wie sie gesammelt wurden, es stellt also sicher das keine fehlinformationen eingetragen werden.

das programm benötigt zugriff zur datenbank, wenn ich das passwort ganz rausnehme kann jeder darauf zugreiffen

und genau aus dem grund soll das passwort auch nicht im source zu sehen sein, damit eben nicht jeder drauf zu greifen kann, eben nur mit dem programm als kontrollinstanz

versteht mich denn keiner oder is das prinzip schwachsinnig?

[mauser]

hi,

nutzt du denn irgendeine Verschlüsselung für die Übertragung ? Ansonsten kannst du das MySql-Passwort ja einfach ersniffen. Aber das eigentlich Design der Software hat halt gewisse Lücken. Sicherheitsüberprüfungen nur auf Clientseite - klingt nicht sehr sicher.
Eine Datenbank mit Schreibzugriff für alle User ? Was machst du wenn du mehr User hast als erwartet und die DB stark anwächst ? Erläutere doch vll. mal deine Anwendung etwas, vll. kann man dann besser helfen.
mfg
mauser

[BeS]

ja alle benutzer sollen dieselbe datenbank schreiben, sie haben zudem ein eigenes user passwort, aber die speicherung von dem ding is ja kein problem
nur aben das passwort um in die datenbank zu schreiben ist ja für alle gleich, muss im programm drin sein, aber eben nicht offen liegen

Also ich habe noch von keinem Programm gehört das sein Passwort in Quellcode hat. Es ist ja auch sinnvoll wenn ein entsprechender Anwender, z.B. der Admin das Passwort ändern kann. Das Passwort sollte also irgendwo ausserhalb liegen, z.B. in einer verschlüsselten Datei. Oder du speicherst es in der Datenbank in einer entsprechenden Tabelle die die Benutzer verwaltet. Alternativ kannst du verschiedene Rollen erstellen und jeder Benutzer der eben in der "schreib"-Rolle ist kann dann auch auf die Datenbank schreibend zugreifen (dann brauchst du garkein schreib-Passwort). Also es gibt viele Möglichkeiten, aber das ein Passwort im Quellcode zu verstecken ist so ziemlich das schlechteste.

[ekle]

eigendlich sollte ihr wenn ich euer programm richtig verstanden habe das anders lösen, sodas der client nicht direkt auf die mysql db zugreifen kann.

ihr solltet einen server programmiern, der die anfragen von euere client software annimmt, überprüft und sicherstellt, dass sie korrekt und erlaubt sind und dann die entsprechenden anweisungen an den db server schickt.

sonst extrahiert irgendjemand aus euerm client die zugangsdaten und kann dann eueren MySQL-Server zuspammen mit falschen einträgen und daten manipulieren oder löschen.

[makko]

die idee mit dem servereigenem kontrollprogramm gefällt mir

nur leider hab ich noch nie was mit serverprogrammierung zu tun gehabt,
kennt da zufällig jemand eine art tutorial, für eine einfache "selbstgebastelte" client-server kommunikation?

[deadeye]

Wenn die Daten die vom Client zum Server gehen nicht allzu groß sind und mehrheitlich aus Text bestehen, kannst Du auf dem Server ja einfach ein PHP-Script laufen lassen, dass von Deiner Anwendung aus aufgerufen wird und mit den Zugangsdaten des Nutzers sowie dessen Nutzdaten gefüttert wird.

Das Script prüft dann erstma, ob der Nutzre(inkl. seinem Passwort) gültig ist und falls ja, verarbeitet es die Nutzdaten, und wenn sie in Ordnung sind, schiebt das PHP-Script die Daten in die Datenbank. Und das allgemeine Schreibpasswort für die DB kannst Du ja dem PHP-Script anvertrauen.

Und wenn der Webserver auf Deinem Server auch mit SSL läuft, hast Du Verschlüsselung des Datenstroms schon geschenkt bekommen.

[ToPeG]

Allso wenn man keine Ahnung von Server-Clentprogrammierung hat, dann würde ich zu zu einem kleinen Webserver (thttpd z.B.)raten, auf dem ein Script (perl, Python, bash, etc.) oder Programm (auch in c, da gibt es auch eine CGI-Lib) aufgerufen wird um die Userdaten zu checken und zu verarbeiten. Die ganze Übertragung kann auch verschlüsselt arbeiten solange man sich auf das HTTP-Protokoll stützt. Das ganze Verbindungesgplänkel wird dann über den Sever geregelt. Zugegriffen wird dann einfach wie über wie über einen Webbrowser. ( was man optional auch programmieren könnte... ) Auch dazu gibt es Libs.
Jedoch muß man dazu bemerken, daß das etwas Prozessorintensiv werden kann, da für jeden Benutzer das Script/Programm neu gestartet wird.
Aber es gibt auch Libs, die einen generischen Server/Client zur Verfügung stellen.
Übrigens wenn manLibs benutzt, die unter der aktuellen GPL stehen, so braucht man das Programm auch nicht zu veröffendlichen wenn es "privat" auf einem Server läuft.