MySQL - Wie Rechte für Zeilen (rows) vergeben?

[Thomas]

Hallo,

soweit ich weiß, kann man bei einer MySQL-Datenbank (ich benutze 5.0) keine Rechte für die Zeilen (Rows, Datensätze) von Tabellen vergeben (im Gegensatz zu Tabellen, Spalten). Es geht dabei darum, daß die meisten Nutzer Zugriff nur auf manche der Datensätze haben sollen, aber eben nicht alle in den jeweiligen Tabellen. Der Bereich, auf den man konkret Zugriff haben darf, ändert sich mit den verschiedenen Benutzergruppen.

Daher meine Frage: wie löst man das am besten?

Meine Idee wäre, in einer extra Tabelle manuell einzutragen, wer auf welchen Bereich Zugriffsrechte hat und das dann in meinen PHP-Abfrage-Skripten stets explizit mit einzubeziehen. Fände ich aber aufwendig und fummelig und würde den Quellcode nur noch mehr aufblähen...

Danke für die Tips
Gruß
Thomas

PS: Es geht dabei um wissenschaftliche Daten, auch wenn das hier anders klingen sollte. ;-)

[King^Lully]

soweit ich weiß, kann man bei einer MySQL-Datenbank (ich benutze 5.0) keine Rechte für die Zeilen (Rows, Datensätze) von Tabellen vergeben (im Gegensatz zu Tabellen, Spalten).

Soweit ich weiss geht das nicht. Rechte auf Datensatzebene sollte der Anwender selbst verwalten. Meinst Du Rechte auf Spaltenebene?

Daher meine Frage: wie löst man das am besten?

Mit bestimmten Attributen in den "Nutzdatentabellen" und einem Rechtesystem, das bspw. durch Tabellen "Sitzungen", "Nutzer" und "Rechte RDBMS-seitig repräsentiert wird.

Meine Idee wäre, in einer extra Tabelle manuell einzutragen, wer auf welchen Bereich Zugriffsrechte hat und das dann in meinen PHP-Abfrage-Skripten stets explizit mit einzubeziehen. Fände ich aber aufwendig und fummelig und würde den Quellcode nur noch mehr aufblähen...

Das mit dem "manuell" eintragen ist schon OK, aber bitte mit Hilfe von Regeln in der Datenzugriffslogik bzw. in einer geeigneten Tabelle (die im Extremfall natürlich auch nur auf einen oder gar keinen Datensatz wirken).

PS: Es geht dabei um wissenschaftliche Daten, auch wenn das hier anders klingen sollte. ;-)

Da müssen wir natürlich höchste Qualitätsstandards beachten und ganz vorsichtig sein.

[Thomas]

Hallo King^Lully,

danke für die Antwort.

soweit ich weiß, kann man bei einer MySQL-Datenbank (ich benutze 5.0) keine Rechte für die Zeilen (Rows, Datensätze) von Tabellen vergeben (im Gegensatz zu Tabellen, Spalten).

Soweit ich weiss geht das nicht. Rechte auf Datensatzebene sollte der Anwender selbst verwalten. Meinst Du Rechte auf Spaltenebene?

Ne, ich meinte in der Tat auf Datensatzebene.

Das mit dem "manuell" eintragen ist schon OK, aber bitte mit Hilfe von Regeln in der Datenzugriffslogik bzw. in einer geeigneten Tabelle (die im Extremfall natürlich auch nur auf einen oder gar keinen Datensatz wirken).

Ja, so in der Tat dachte ich mir das.

PS: Es geht dabei um wissenschaftliche Daten, auch wenn das hier anders klingen sollte. ;-)

Da müssen wir natürlich höchste Qualitätsstandards beachten und ganz vorsichtig sein.

So ises. ;-))

Eben habe ich auf eine ähnliche Frage gelesen, man könne das auch mit VIEWs machen, woanders hieß es dazu aber, diese seien nicht "sicher". Was meinst du dazu?

Gruß
Thomas

[King^Lully]

Eben habe ich auf eine ähnliche Frage gelesen, man könne das auch mit VIEWs machen, woanders hieß es dazu aber, diese seien nicht "sicher". Was meinst du dazu?

VIEWs könnte man tatsächlich nutzen, haben wir aber nie gemacht, stattdessen haben wir in jede auf Daten zugreifende stored procedure eine Rechteprüfung gemacht, also möglichst nah am Daten-System und nicht in der umgebenden Logik (wo diese Überprüfung definitiv auch nicht hingehören würde).

Hmm, auf den ersten Blick liest sich das ganz schick mit den Rechten, die vertikal filtern und per VIEW realisiert sind, allerdings dürfte es da, wenn es nicht ums reine SELECTieren geht, komplex werden. Für uns schwer zu sagen, ob die Idee gut ist.

[King^Lully]

Nachtrag:
Wir vergassen zu erwähnen, dass VIEWs per se böse sind.

[Matzberger Marcus]

Hallo,

Wir vergassen zu erwähnen, dass VIEWs per se böse sind.

Interessant, inwiefern?

Grüße
Marcus

[King^Lully]

Wir vergassen zu erwähnen, dass VIEWs per se böse sind.
Interessant, inwiefern?

Man braucht keine Sichten. Einzige uns bekannte vernünftige Anwendung für dieses Objekt ist die Schemasicht auf RDBMS-eigene Datenbasen, die eine zusätzliche Abstraktionsebene einzieht und unabhängig von in späteren Versionen zu erwartenden Designänderungen an der Systemdatenhaltung zukünftige Kompatibilität und Abhängigkeiten vermeidet. [1]

Demzufolge vermeiden wir in unseren Applikation bestmöglich Sichten und arbeiten stattdessen mit stored procedures, die Datensatzmengen zurückliefern, also SELECTieren.

Warum aber sind VIEWs böse? Nun, erst einmal haben wir eine zusätzlich eingezogene Schicht, die nicht benötigt wird. (Es kann bspw. bei eher wenig erfahrenen Entwicklern oft zu "Vers(ch)ichtungen" kommen, Sichten, die auf Sichten, die auf Sichten basieren. LOL)
Zudem kann man Sichten und deren Abhängigkeiten schlecht verwalten. Aber darüber darf diskutiert werden und wir wollen nicht auf diesem Argument bestehen.

Q:Warum gibt es Sichten?
A:Der Markt verlangt Sichten.

[1] Ebenso heisse Eisen wie die VIEWs sind bspw. die TRIGGER und die CASCADING DELETES, wobei es für Trigger immer hin noch den Anwendungsbereich "Alarmmeldungen" gibt.

[Matzberger Marcus]

Hallo,

Man braucht keine Sichten.

...
So gesehen braucht man auch keine Datenbanken, man kann alles auch selber in einer Programmiersprache und ein paar Files umsetzen

Warum aber sind VIEWs böse? Nun, erst einmal haben wir eine zusätzlich eingezogene Schicht, die nicht benötigt wird. (Es kann bspw. bei eher wenig erfahrenen Entwicklern oft zu "Vers(ch)ichtungen" kommen, Sichten, die auf Sichten, die auf Sichten basieren. LOL)

Dafür gibt es Code Reviews ;-)

Ein Beispiel wann Views sehr brauchbar sind sind historisierte Tabellen. Dann gibt es die Tabellen, die die gesamte Historie enthalten, und die Views, die nur die aktuell gültigen Werte zeigen.

[1] Ebenso heisse Eisen wie die VIEWs sind bspw. die TRIGGER und die CASCADING DELETES, wobei es für Trigger immer hin noch den Anwendungsbereich "Alarmmeldungen" gibt.

Auch hier würde ich eine Historisierung der Daten als Beispiel nehmen. Kein Programmierer braucht sich Gedanken über das Historisierungskonzept zu machen, da dies automatisch bie DML-Aktionen durch die entsprechenden Trigger geschieht.

Deine Argumentation erweckt den Eindruck, dass du diese Möglichkeiten ablehnst, weil jemand damit schlechte Anwendungen schreiben kann.

Grüße
Marcus

[King^Lully]

Man braucht keine Sichten.
...
So gesehen braucht man auch keine Datenbanken, man kann alles auch selber in einer Programmiersprache und ein paar Files umsetzen

So darf man nicht aber argumentieren. (Davon unabhängig: Datenbasen sind immer erforderlich, vermutlich meinst Du DBSe. Nun, ich kenne gute Datenhaltungen, die auf ISAM-Dateien basieren, aber Du weisst hoffentlich, warum SQL SQL heisst?)

Warum aber sind VIEWs böse? Nun, erst einmal haben wir eine zusätzlich eingezogene Schicht, die nicht benötigt wird. (Es kann bspw. bei eher wenig erfahrenen Entwicklern oft zu "Vers(ch)ichtungen" kommen, Sichten, die auf Sichten, die auf Sichten basieren. LOL)
Dafür gibt es Code Reviews ;-)

Keine Ahnung, ob Du das ernst meinst. (Falls ja: Designfehler sollte man nicht reviewen sondern vorbeugend per policies bearbeiten.)

Ein Beispiel wann Views sehr brauchbar sind sind historisierte Tabellen. Dann gibt es die Tabellen, die die gesamte Historie enthalten, und die Views, die nur die aktuell gültigen Werte zeigen.

Einspruch: Wir kennen zumindest zwei bessere Verfahren für die Historisierung, entweder spezielle History-DBs, die nicht mehr aktuelle Datensätze enthalten oder "n:m"s mit Versionierungen der Datensätze.

[1] Ebenso heisse Eisen wie die VIEWs sind bspw. die TRIGGER und die CASCADING DELETES, wobei es für Trigger immer hin noch den Anwendungsbereich "Alarmmeldungen" gibt.
Auch hier würde ich eine Historisierung der Daten als Beispiel nehmen. Kein Programmierer braucht sich Gedanken über das Historisierungskonzept zu machen, da dies automatisch bie DML-Aktionen durch die entsprechenden Trigger geschieht.

OK, Historisierung per Trigger haben wir auch mal umgesetzt. Würden wir nicht mehr so machen sondern stattdessen in den betreffenden DML-SPs Historisierungs-Code unterbringen. (Dann muss man bspw. auch nicht die ganzen Trigger ab- und zuschalten, wenn mal administrativer oder OLAP-Datenzugriff erfolgt. Schon mal das "vergessene Trigger-Problem" bearbeitet? (Oder das "vergessene FK-Problem"? ;))

Deine Argumentation erweckt den Eindruck, dass du diese Möglichkeiten ablehnst, weil jemand damit schlechte Anwendungen schreiben kann.

Da ist was dran. Man kann sicherlich ohne weiteres Spezialfälle konstruieren, in denen die angelieferten Objekte höchst geeignet sind. (Oft bei "Einmal-SW", die keinen echten Lebenszyklus hat. ;)

SW solte immer möglichst DAU-fähig sein.

Aber interessant, habe die VIEWs-Geschichte mit vielen Leuten diskutiert, fast alle versuchten aus mehr oder weniger bewussten Gründen VIEWs zu meiden.

[Matzberger Marcus]

Hallo,

Dafür gibt es Code Reviews ;-)

Keine Ahnung, ob Du das ernst meinst. (Falls ja: Designfehler sollte man nicht reviewen sondern vorbeugend per policies bearbeiten.)

Du hast recht, bei uns gibt es strenge Entwicklungsrichtlinien, nichts desto trotz ist ein Code Review notwendig, damit man weiß ob der Entwickler die Standards auch einhält.

Einspruch: Wir kennen zumindest zwei bessere Verfahren für die Historisierung, entweder spezielle History-DBs, die nicht mehr aktuelle Datensätze enthalten oder "n:m"s mit Versionierungen der Datensätze.

Ob dieser Ansatz besser ist hängt von den Anforderungen ab. Eine View, die so gestaltet ist, dass ein Parameter ermöglicht Daten anzuzeigen, die zu einem bestimmten Zeitpunkt gültig waren (sie können historisiert sein oder immer noch aktuell), erleichtert ad hoc Abfragen ungemein. Habe ich die Information in zwei Tabellen wird die Abfrage entsprechend komplexer.

OK, Historisierung per Trigger haben wir auch mal umgesetzt. Würden wir nicht mehr so machen sondern stattdessen in den betreffenden DML-SPs Historisierungs-Code unterbringen. (Dann muss man bspw. auch nicht die ganzen Trigger ab- und zuschalten, wenn mal administrativer oder OLAP-Datenzugriff erfolgt. Schon mal das "vergessene Trigger-Problem" bearbeitet? (Oder das "vergessene FK-Problem"? ;))

"Unsere" Historisierungstrigger lassen sich global per Funktion auf Sessionebene abschalten. Da ist es nicht so leicht etwas zu vergessen.

Aber interessant, habe die VIEWs-Geschichte mit vielen Leuten diskutiert, fast alle versuchten aus mehr oder weniger bewussten Gründen VIEWs zu meiden.

Es gibt immer wieder Fremdsysteme, die auf unsere Daten zugreifen. Wir stellen diese soweit möglich als View zur Verfügung, da Änderungen an unseren Tabellen damit nicht durchschlagen und außerdem Views keine Probleme bei verschiedenen Zugriffstechniken machen.

Manche Anforderungen lassen sich performant auch kaum anders als über Views umsetzen. Gerade in diesem Punkt sind Views jeder Prozedur weit überlegen.

Grüße
Marcus

[King^Lully]

Es gibt immer wieder Fremdsysteme, die auf unsere Daten zugreifen. Wir stellen diese soweit möglich als View zur Verfügung, da Änderungen an unseren Tabellen damit nicht durchschlagen und außerdem Views keine Probleme bei verschiedenen Zugriffstechniken machen.

Exakt dafür sind VIEWS OK. (Bzw. wären OK, wenn SPs nicht auch dafür (vielleicht :) besser geeignet wären. :)

Manche Anforderungen lassen sich performant auch kaum anders als über Views umsetzen. Gerade in diesem Punkt sind Views jeder Prozedur weit überlegen.

Performanceüberlegungen sind oft die letzte Rückzugslinie.   ;)

[Matzberger Marcus]

Hallo,

Performanceüberlegungen sind oft die letzte Rückzugslinie.   ;)

Aber diese Linie ist praktisch uneinnehmbar ;-)

Grüße
Marcus

[King^Lully]

Performanceüberlegungen sind oft die letzte Rückzugslinie.   ;)
Aber diese Linie ist praktisch uneinnehmbar ;-)

Diese datenbankphilosophischen Fragestellungen sind oft sehr vielschichtig. Viele Aspekte (aber nicht die wichtigsten ;) werden oft auch von uns übersehen bzw. vernachlässigt. In diesem Fall ist noch nachzutragen, dass sowohl die von uns anfänglich zitierten Systemsichten als auch die von Dir zitierten "Sichten für Externe" insofern besonders sind, da der Zugriff aus einem anderen System heraus erfolgt.

Vielleicht kann man festhalten, dass für systemfremde Datenzugriffe Sichten geeignet sind, sofern diese bewusst eine Abstraktionseben darstellen und der Zugriff von extern SQL-basiert (also von anderen SQL-sprechenden Systemen erfolgt) ist. (Bei XML-basiertem Zugriff würden wir nicht mit Sichten kommen wollen, selbst wenn diese Objekte mittlerweile XML-fähig sein sollten.)

[Matzberger Marcus]

Hallo,

In diesem Fall ist noch nachzutragen, dass sowohl die von uns anfänglich zitierten Systemsichten als auch die von Dir zitierten "Sichten für Externe" insofern besonders sind, da der Zugriff aus einem anderen System heraus erfolgt.

Selbst für systeminterne Zugriffe kann eine View richtig sein. Wenn ich Daten normalisiert habe, die ich häufig zusammen brauche, verwende ich eine View für den Zugriff. So ist sichergestellt, dass die Verknüpfung konsistent ist. Warum soll ich in jeder SP wieder das gleiche machen nur weil ich einen anderen Teil der Daten brauche?
Views, Trigger und andere Möglichkeiten einer Datenbank haben ihre Berechtigung dort wo sie Datenintegrität sichern und Zugriffe vereinfachen. Ob ich sie verwende ist dann aber oft eine Glaubensfrage.

Grüße
Marcus

[King^Lully]

Selbst für systeminterne Zugriffe kann eine View richtig sein.

OK, das ist der Dissenz.

Wenn ich Daten normalisiert habe, die ich häufig zusammen brauche, verwende ich eine View für den Zugriff.

Sorry, aber das sind gleich zwei andere Fässer, die Du hier öffnen möchtest.

So ist sichergestellt, dass die Verknüpfung konsistent ist.

Da schauen wir schon wieder etwas blass.

Warum soll ich in jeder SP wieder das gleiche machen nur weil ich einen anderen Teil der Daten brauche?

Selbstverständlich sollte der besondere und benötigte Zugriff dann in einer SP gekapselt sein, die ggf. wiederum von anderen SPs aufgerufen wird.

Views, Trigger und andere Möglichkeiten einer Datenbank haben ihre Berechtigung dort wo sie Datenintegrität sichern und Zugriffe vereinfachen. Ob ich sie verwende ist dann aber oft eine Glaubensfrage.

Für uns nicht, aber das wäre wieder der o.g. Dissenz. "Datenintegrität" hat nichts mit VIEWs zu tun, aber was solls, wir gehen da einfach nicht mehr darauf ein.

[apfelsine]

Hi,

das interessiert mich jetzt und ich muß dazu sagen,
es überzeugt mich noch nicht.

Aus welcher Perspektive heraus sind Views für dich sinnlos?

Manche Anforderungen einer Anwendung sind performanter
und erheblich einfacher zu implementieren, wenn Views
verwendet werden. Ob ich das Statement im Code zusammenbastel
oder in eine View stopfe ist in dem Fall (erstmal) egal.
Aber in der DB ist es strukturell besser aufgehoben,
als im Programmcode.

Eine vernünftige Anwendung? Das hört sich fast wie
die Grundsatzdiskussion an, ob es einen Wertezustand NULL geben muß
oder nicht.

Warum aber sind VIEWs böse? Nun, erst einmal haben wir eine zusätzlich eingezogene Schicht, die nicht benötigt wird. (Es kann bspw. bei eher wenig erfahrenen Entwicklern oft zu "Vers(ch)ichtungen" kommen, Sichten, die auf Sichten, die auf Sichten basieren. LOL)

Ein schlechtes DB-Design fängt bei den Tabellen an und hört mindestens bei den Sichten auf. Aber niemand käme auf die Idee deswegen Tabellen böse zu nennen :-)

Ein System das diverse Freiheiten lässt überlässt dem Designer eben
eine Verantwortung. Wenn der dann mit Esstäbchen drin rumfurwerken muß, ist das schmerzhaft aber in der Form wohl kaum zu vermeiden.

Grüße
apfelsine

[King^Lully]

Aus welcher Perspektive heraus sind Views für dich sinnlos?

Views sind nicht sinnlos, sondern überflüssig, rein dem Markt geschuldete Objekte, um die Produktpalette etwas kompletter erscheinen zu lassen.

Ein System das diverse Freiheiten lässt überlässt dem Designer eben
eine Verantwortung. Wenn der dann mit Esstäbchen drin rumfurwerken muß, ist das schmerzhaft aber in der Form wohl kaum zu vermeiden.

Schlechte SW-Tools unterstützen bzw. generieren schlechte Entwickler, sogar das Verschleiern eigener Mangel-, Minder-, Fehl- und Minusleistungen wird denen so erleichtert.

[apfelsine]

Aus welcher Perspektive heraus sind Views für dich sinnlos?

Views sind nicht sinnlos, sondern überflüssig, rein dem Markt geschuldete Objekte, um die Produktpalette etwas kompletter erscheinen zu lassen.

Das ist keine stichhaltige Begründung.
Hol ein wenig aus wenns sein muß.
Es kommt niemand auf die Idee er wäre Arzt, weil
er weiß wie man ein Pflaster auf die Wunde klebt.
In der Informatik meint eben jeder in allem herumpfuschen zu können.
Aber DAS ist keine geeignete Begründung als Erklärung
wieso Views überflüssig sind, warum sie zu vermeiden sind
und was Stored Procedures von Views denn dann in dem Fall
abhebt.

Schlechte SW-Tools unterstützen bzw. generieren schlechte Entwickler, sogar das Verschleiern eigener Mangel-, Minder-, Fehl- und Minusleistungen wird denen so erleichtert.

Wie wärs wenn wir wieder mit Lochkarten anfangen?
Dauert zwar ein paar Minuten länger, aber dann kannste sicher sein,
das der Entwickler sich sein Programm bestimmt überlegt hat.

[king^Lully]

Aus welcher Perspektive heraus sind Views für dich sinnlos?

Views sind nicht sinnlos, sondern überflüssig, rein dem Markt geschuldete Objekte, um die Produktpalette etwas kompletter erscheinen zu lassen.

Das ist keine stichhaltige Begründung.

Wenn wir hier die Verständigkeit, Kompetenz und Leistungsbereitschaft einiger Entwickler hier betrachten, fragen wir uns ernsthaft ob nicht die nächste UN-Resolution den Jungs hier gelten sollte.

Schlechte SW-Tools unterstützen bzw. generieren schlechte Entwickler, sogar das Verschleiern eigener Mangel-, Minder-, Fehl- und Minusleistungen wird denen so erleichtert.

Wie wärs wenn wir wieder mit Lochkarten anfangen?
Dauert zwar ein paar Minuten länger, aber dann kannste sicher sein,
das der Entwickler sich sein Programm bestimmt überlegt hat.

Ganz wichtig auch die Sanktionen und eine internationale Gemeinschaft, die Inspektoren und die nötige Überwachungsinfrastruktur für die Knallfrösche hier bereitstellt.
Mit Mandat also, meine Herren! Aber keine Friedenstruppe.

[Thomas]

VIEWs könnte man tatsächlich nutzen, haben wir aber nie gemacht, stattdessen haben wir in jede auf Daten zugreifende stored procedure eine Rechteprüfung gemacht, also möglichst nah am Daten-System und nicht in der umgebenden Logik (wo diese Überprüfung definitiv auch nicht hingehören würde).

Hmm, auf den ersten Blick liest sich das ganz schick mit den Rechten, die vertikal filtern und per VIEW realisiert sind, allerdings dürfte es da, wenn es nicht ums reine SELECTieren geht, komplex werden. Für uns schwer zu sagen, ob die Idee gut ist.

Bis jetzt würde das auch nur das SELECTieren betreffen, denn Daten einlesen oder ggf. verändern tun nur wir, die DB-Verwalter. Von daher danke für deine Meinung.

Nachtrag:
Wir vergassen zu erwähnen, dass VIEWs per se böse sind.

Also doch Sicherheitsprobleme? Bei uns wäre es jetzt nicht existenzbedrohend, wenn Daten von Unberechtigten zu lesen wären, wäre aber definitiv nicht erwünscht.

Gruß
Thomas

[King^Lully]

Nachtrag:
Wir vergassen zu erwähnen, dass VIEWs per se böse sind.

Also doch Sicherheitsprobleme? Bei uns wäre es jetzt nicht existenzbedrohend, wenn Daten von Unberechtigten zu lesen wären, wäre aber definitiv nicht erwünscht.

Die "Sicherheitsprobleme", die Du zitiert hast, meinen wir zu verstehen, sollten aber bei Deinem Vorhaben _keine_ Rolle spielen, VIEWs sind per se zweifelhaft (einzige uns bekannte sinnvolle Objektanwendung: Schemasichten auf RDBMS-eigene Systemtabellen).

Also, komm ruhig mit vrscheidenen Sichten für die Nutzer.

[Thomas]

Die "Sicherheitsprobleme", die Du zitiert hast, meinen wir zu verstehen, sollten aber bei Deinem Vorhaben _keine_ Rolle spielen, VIEWs sind per se zweifelhaft (einzige uns bekannte sinnvolle Objektanwendung: Schemasichten auf RDBMS-eigene Systemtabellen).

Also, komm ruhig mit vrscheidenen Sichten für die Nutzer.

Alles klar, danke.

Thomas