PHP MySQL Rechtesystem ausreizen

[Tom]

Hello,

wer von Euch hat das Rechtesystem von MySQL in Verbindung mit der PHP-API schon mal voll ausgereizt?

Was sollten man lieber lassen und was funktioniert gut, und vor allem _wie_ funktioniert es.

Horizontale Rechteverwaltung bis aus Feldebene:
Wie kann man _vorher_ feststellen, welcher User welche Rechte hat, um im Formular nur die zutreffenden Felder (Splaten)  und Funktionen anzubieten?

Vertikale Rechteverwaltung:
gibt's mWn bei MySQL nicht, muss man selber basteln... oder?

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Mike©]

Moin Tom,

wo nimmst Du eigentlich Deine Fragen her?
Manchmal habe ich den Eindruck, dass Deine Hauptbeschäftigung darin besteht, Fragen zu konstruieren ;-)

Felder (Splaten)  und Funktionen anzubieten?

die "Splaten" als solches waren mal weit verbreitet, sind aber IMHO mittlerweile ausgestorben.

regds
Mike©

[Tom]

Hello,

wo nimmst Du eigentlich Deine Fragen her?

aus der täglichen Praxis und dem "Kickback" eines jeden Lernenden

Manchmal habe ich den Eindruck, dass Deine Hauptbeschäftigung darin besteht, Fragen zu konstruieren ;-)

Nun, eine Frage muss schon eine gewisse Konstruktion haben, damit sie überhaupt verstanden wird.
Ich beschäftige mich tatsächlich manchmal ganz schön lange damit, wie ich meinen momentanen Unverstand in eine allgemein- oder fachleutespezifische Frage kleiden kann...

Felder (Splaten)  und Funktionen anzubieten?

die "Splaten" als solches waren mal weit verbreitet, sind aber IMHO mittlerweile ausgestorben.

Tippfehler kan  ich gut...

Also "Spalten" oder "Felder"

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Mike©]

Moin Tom,

Tippfehler kan  ich gut...

Indeed          ^^ *LOL*

Leider kann ich Deine Frage nicht beantworten, aber ich bin gespannt.
regds
Mike©

[Sven Rautenberg]

Moin!

wer von Euch hat das Rechtesystem von MySQL in Verbindung mit der PHP-API schon mal voll ausgereizt?

Ich frage mich, mit welchem Sinn das passieren sollte.

Sicherlich ist es schlau, je Projekt und/oder Website-VHost-User eigene DB-Zugänge zu vergeben, um die Möglichkeiten des gegenseitigen unberechtigten Zugriffs zu unterbinden.

Das aber innerhalb eines Projektes noch weiter auszureizen scheint mir nicht so ganz einsichtig zu sein. Solche Rechtevergabe ist schlau, wenn man tatsächlich mehrere nicht miteinander kommunizierende DB-User (Menschen mit ihrem CLI-Interface) hat, welche per SQL-Kommandos die Datenbank benutzen.

Da aber bei PHP der Webserver zwingend lesenden Zugriff auf alle PHP-Dateien, als auch die mit den Zugangsdaten zur DB, hat, wäre es im Angriffsfall nur eine Frage der Zeit, bis der Angreifer nicht nur den eingeschränkten Nur-Lese-Account gefunden, sondern auch den Vollzugang zur Datenbank aufgespürt hat und einsetzt.

Wirklich einsetzbar und einen echten Sicherheitsvorteil bringen würde so ein System also nur in Szenarien, in denen
a) der DB-Server separat auf einer eigenen Maschine untergebracht ist
b) Skripte mit unterschiedlichen DB-Zugriffsrechten ebenfalls auf unterschiedlichen Maschinen untergebracht sind, oder zumindest extrem gegen gegenseitiges Lesen abgeschottet.

Beispielsweise wenn ein öffentliches DB-Frontend nur lesen darf, und die Administration aus dem gesicherten Intranet über ein weiteres Frontend stattfindet.

Was sollten man lieber lassen und was funktioniert gut, und vor allem _wie_ funktioniert es.

Ich würde die Funktionsfähigkeit derartiger Rechtesysteme innerhalb der DBMS als ausgezeichnet bezeichnen wollen. Und "wie" es funktioniert, sollte dich als DB-Benutzer nicht weiter interessieren - das macht die Datenbank schon irgendwie, und das Interface dafür ist SQL.

- Sven Rautenberg

[Tom]

Hello,

könnte es vielleicht sein, dass Du mich falsch verstanden hast?

Ich möchte die Zugriffsrechte auf den Datenstamm so komprimiert verwalten, wie es irendwie geht.
Da MySQL leiser noch keine vollwertige Client-Server-SQL-Datenbank ist, also Trigger und SPs noch nicht unterstützt werden (oder habe ich das übersehen?), muss man also abwägen, welche Rechte im DBMS verankert werden und welche im API.

Das Problem liegt dann darin, wieviele APIs man zulässt und welchen Schaden die Differenzen zwischen den APIs auslösen könnten.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Sven Rautenberg]

Moin!

Hello,

könnte es vielleicht sein, dass Du mich falsch verstanden hast?

Dann hast du schlecht gefragt. Es ging dir augenscheinlich um "wer von Euch hat das Rechtesystem von MySQL in Verbindung mit der PHP-API schon mal voll ausgereizt?"

Und über das Rechtesystem von MySQL habe ich berichtet. Dein Hinweis auf die PHP-API sticht dabei nicht wirklich ins Auge, weil die einzige direkte API für MySQL eben die mysql_*-Funktionen sind - über ODBC würde ich MySQL nicht wirklich anbinden wollen. Und von PEAR hast du auch nichts erzählt.

Ich möchte die Zugriffsrechte auf den Datenstamm so komprimiert verwalten, wie es irendwie geht.
Da MySQL leiser noch keine vollwertige Client-Server-SQL-Datenbank ist, also Trigger und SPs noch nicht unterstützt werden (oder habe ich das übersehen?), muss man also abwägen, welche Rechte im DBMS verankert werden und welche im API.

Trigger und Stored Procedures/Functions gibts ab MySQL 5.0. Und das würde ich nicht als "keine vollwertige Client-Server-SQL-Datenbank" bezeichnen, denn das ist MySQL. Es fehlen ihr lediglich noch ein paar Features, die aber mit dem Client oder Server an sich nichts zu tun haben.

Die Sache ist doch die: Wenn dein Konstrukt, was auch immer du planst, mit MySQL nicht realisierbar scheint, dann solltest du dir eine bessere Datenbank aussuchen. PostgreSQL existiert.

Das Problem liegt dann darin, wieviele APIs man zulässt und welchen Schaden die Differenzen zwischen den APIs auslösen könnten.

Dir geht es also um die API vor der API? Das ist doch komplett deine Sache, auch was Differenzen darin angeht. Mit PHP kann man eben nur einen unzureichenden Ersatz für in der DB nicht existente Features bauen - egal wie viel Mühe man sich gibt, eine Garantie beispielsweise für die korrekte referentielle Integrität ist unmöglich, und Transaktionen müssen beispielsweise auch zwingend auf DB-Ebene existieren, um funktionieren zu können.

Ich schätze also, es geht dir vielmehr um die Problematik der Rechte der Benutzer des PHP-HTML-Interfaces, und weniger um die Rechte, die der lesende und schreibende MySQL-Account auf Spalten-, Tabellen- und Datenbank- sowie auf Kommandoebene besitzt.

- Sven Rautenberg

[Tom]

Hello,

Ich schätze also, es geht dir vielmehr um die Problematik der Rechte der Benutzer des PHP-HTML-Interfaces, und weniger um die Rechte, die der lesende und schreibende MySQL-Account auf Spalten-, Tabellen- und Datenbank- sowie auf Kommandoebene besitzt.

Immer noch nicht ganz.
Es geht mir darum, MySQL über verschieden Wege, also Interfaces, benutzen zu können, bei möglichst zentraler Rechteverwaltung. Einer der Wege ist ein in C++ erstellter Client, der direkt auf den Port zugreift, ein anderer ist eben der Zugriff über HTTP und PHP.

Und um dies umsetzen zu können, fragte ich nach den Möglichkeiten, die MySQL bietet. Da ich immer noch auf einer 3er Version und einer 4.0x arbeite, und das auch noch eine Weile so bleibt, kenne ich mich z.B. mit der 5er überhaupt noch nicht aus.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Sven Rautenberg]

Moin!

Immer noch nicht ganz.
Es geht mir darum, MySQL über verschieden Wege, also Interfaces, benutzen zu können, bei möglichst zentraler Rechteverwaltung. Einer der Wege ist ein in C++ erstellter Client, der direkt auf den Port zugreift, ein anderer ist eben der Zugriff über HTTP und PHP.

Gut, dann gilt meine erste Antwort doch: Die Rechte müssen dann nämlich komplett durch MySQL garantiert und kontrolliert werden, irgendwelcher Code davor wäre dann als nicht unbedingt zuverlässig zu bezeichnen.

Und sofern du dann wirklich Trigger und SP brauchst, hast du eben gerade die falsche DB im Einsatz.

Und um dies umsetzen zu können, fragte ich nach den Möglichkeiten, die MySQL bietet.

MySQL bietet die Möglichkeit, bis hin zur Spalte und zum Kommando je Account (der auch noch je nach Quell-IP unterschieden werden kann) die Zugriffsmöglichkeiten einzuschränken. Es ist also problemlos möglich, einem Account nur SELECT und UPDATE auf eine einzige Spalte einer Tabelle zu erlauben, wenn dieser Account sich nicht von einer bestimmten IP aus eingeloggt hat.

Andererseits ist dieses System eben relativ sinnlos (wie ich schon ausführte), wenn der tatsächliche Client immer derselbe Webserver ist, der sich auch immer mit denselben Benutzerdaten bei MySQL anmeldet, dessen menschliche Benutzer aber unterschiedliche Möglichkeiten haben sollen. Da würde ich dann einfach ein System wie PhpMyAdmin mit HTTP-Authentifizierung empfehlen - dann gibt jeder Benutzer seine Accountdaten direkt ein, welche dann für den Kontakt mit MySQL verwendet werden - und schon kann der Benutzer auch wieder nur das tun, was ihm in MySQL erlaubt ist.

- Sven Rautenberg

[Tom]

Hello Sven,

Es geht mir darum, MySQL über verschieden Wege, also Interfaces, benutzen zu können, bei möglichst zentraler Rechteverwaltung. Einer der Wege ist ein in C++ erstellter Client, der direkt auf den Port zugreift, ein anderer ist eben der Zugriff über HTTP und PHP.

Gut, dann gilt meine erste Antwort doch: Die Rechte müssen dann nämlich komplett durch MySQL garantiert und kontrolliert werden, irgendwelcher Code davor wäre dann als nicht unbedingt zuverlässig zu bezeichnen.

Und sofern du dann wirklich Trigger und SP brauchst, hast du eben gerade die falsche DB im Einsatz.

Trigger würde ich für die vertikale Kontrolle benutzen wollen.

Bsp: Akqusitionsdaten einer Verkaufsorganisation
     Es gibt mehrere Verkäufer
     Jeder Verkäufer darf nur die Kundendaten ändern, die ihm zugewiesen sind
     Über den Trigger beim update kann man nun die Prüfroutine ansprechen.
     Diese schaut in einer weiteren Tabelle nach, ob der Knabe für diesen _SATZ_
      die Berechtigung zum Ändern hat.

Das Problem, auf Satzebene (Zeile) Regeln einzurichten und zu überwachen, versuche ich möglichst zentral zu lösen. Wahrscheinlich hast Du recht, dass MySQL ( bis 4.x) dazu noch nicht geeignet ist.

In PHP konnte ich das bisher leicht lösen. Es greifen eben alle Scripte immer nur über das "Common PHP Interface" zu. Aber wenn nun auch noch Zugriffsmöglichkeiten auf die DB über andere Clients stattfinden sollen, wird es schwer sein, die Regeln harmonisiert zu halten.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Sven Rautenberg]

Moin!

In PHP konnte ich das bisher leicht lösen. Es greifen eben alle Scripte immer nur über das "Common PHP Interface" zu. Aber wenn nun auch noch Zugriffsmöglichkeiten auf die DB über andere Clients stattfinden sollen, wird es schwer sein, die Regeln harmonisiert zu halten.

Wie du schon richtig erkannt hast: Entweder sorgt die Datenbank für eine eindeutige und nicht umgehbare Kontrolle des Zugriffs, oder eben eine einzige vorgelagerte API - was wiederum bedeuten würde, dass diese "anderen Clients" sich eben nicht direkt mit der DB verbinden dürfen, sondern lediglich mit einem entsprechend konstruierten Interface, welches zusätzliche Prüfungen realisiert.

Ob man sowas aber auf PHP-Basis realisieren sollte, würde ich mal stark in Zweifel ziehen. :) Obwohl: Grundsätzlich kann man mit PHP echt lustige Dinge machen. Ein Interface z.B. für XMLRPC besteht, und man kann auch einen Demon in PHP schreiben (dann per PHP-CLI, und nicht im Webserver). Für Anwendungen mit eher geringen Anforderungen an die Performance sollte sowas keine allzu großen Probleme aufwerfen, es erfordert nur entsprechende Kenntnisse hinsichtlich der Programmierung von Multi-Prozess-Anwendungen.

- Sven Rautenberg

[Tom]

Hello,

[...] es erfordert nur entsprechende Kenntnisse hinsichtlich der Programmierung von Multi-Prozess-Anwendungen.

Die "normalen" Multiprozessumgebungen machen mir da keine Kopfzerbrechen mehr.
Das mit dem "General Common PHP Interface" wollen wir dann lieber vergessen. Da übnerlege ich mir lieber, entweder mittels C-Programmierung in MySL einzudringen (geht ja schließlich auch) oder doch den DB-Wechsel durchzusetzen.

Allerdings muss ich mich noch an die Versuche von berlin-Eddi erinnern, auf einem Multiprozessorsystem sowas umzusetzen. da gab es wohl mit PHP noch erhebliche Probleme...

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom