MySQL-Rechte Verständnisfrage DROP + CREATE

[djcrackman]

Wünsche mal einen guten Morgen ...

ich hab hier gerade ein Brett vor dem Kopf ... dürfte ein 4-Kant mit 20cm Kantenlänge haben *uah*.

Ich müsste folgendes umsetzen:

User X hat 5 Datenbanken zur Verfügung.
Er kann in den Datenbanken machen was er will (Tabellen erstellen, löschen, umbenennen, etc).
Er darf die 5 ihm zur Verfügung gestellten Datenbanken nicht löschen können.
Er darf keine Datenbanken erstellen können.

Soweit so gut, bisher habe ich das so realisiert:

mysql.db

Code: Select all

+--------+-------------+-----------+-------------+-----------+
| Host   | Db          | User      | Create_priv | Drop_priv |
+--------+-------------+-----------+-------------+-----------+
| mysql4 | test-user01 | test-user | Y           | Y         |
| mysql4 | test-user02 | test-user | Y           | Y         |
| mysql4 | test-user03 | test-user | Y           | Y         |
| mysql4 | test-user04 | test-user | Y           | Y         |
| mysql4 | test-user05 | test-user | Y           | Y         |
+--------+-------------+-----------+-------------+-----------+

mysql.user

Code: Select all

+--------+-----------+-------------+-----------+
| host   | User      | Create_priv | Drop_priv |
+--------+-----------+-------------+-----------+
| mysql4 | test-user | Y           | Y         |
+--------+-----------+-------------+-----------+

Sofern ich nicht total blöde bin, sollte der User jetzt die Rechte haben, in den ihm zugewiesenen Datenbanken zu walten wie er will. Leider kann er auch seine DB's löschen -> er kann dafür auch nur seine eigenen erstellen. Würde soweit passen, aber mir geht es um das CREATE/DROP der DB selbst.

Alternativ habe ich bereits versucht global DROP/CREATE zu verbieten und dann per tables_priv für Tabelle % wieder zu erlauben, hat jedoch leider nicht funktioniert.

Habe ich einen Denkfehler, oder besteht tatsächlich keine Möglichkeit, diese Version der Berechtigungen durchzusetzen?

PS: Die Idee mit tables_priv habe ich von da: http://dev.mysql.com/doc/refman/5.0/en/privileges.html

[Joe User]

Lies Dir mal http://dev.mysql.com/doc/refman/5.0/en/grant.html durch, dann sollte Dir das 4-Kant auf die Füsse fallen ;)

[djcrackman]

Habe ich bereits gelesen ... jetzt das 5te Mal. Kann mir mal bitte jemand virtuell das 4-Kant drüber ziehen? Schläge auf den Hinterkopf sollen ja helfen ...

Code: Select all

 GRANT CREATE,DROP ON `test-user01`.* TO `test-user`@`mysql4`

"Gut, machste mal" denk ich mir -> führt zum gleichen Ergebnis wie vorher: der User kann die DB löschen.

Entweder ich bin blind, blöd oder unfähig ... aber wenn ich das richtig verstehe, dann sollte ich doch am richtigen Dampfer liegen?

Code: Select all

global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges
OR routine privileges

Das bedeutet doch, dass wenn ich global CREATE/DROP verbiete und es dann per mysql.tables_priv für % wieder erlaube, dass der User Tabellen erstellen und löschen können sollte?

Hilfe, danke :(

[aubergine]

Wenn du nur Datenbank spezifische Rechte an den User verteilst (in dem fall für alle 5 db's) und keine globalen, sollte alles so laufen wie du es brauchst.

[djcrackman]

@aubergine Du meinst im Sinne von:

mysql.db

Code: Select all

+--------+-------------+-----------+-------------+-----------+
| Host   | Db          | User      | Create_priv | Drop_priv |
+--------+-------------+-----------+-------------+-----------+
| mysql4 | test-user01 | test-user | Y           | Y         |
| mysql4 | test-user02 | test-user | Y           | Y         |
| mysql4 | test-user03 | test-user | Y           | Y         |
| mysql4 | test-user04 | test-user | Y           | Y         |
| mysql4 | test-user05 | test-user | Y           | Y         |
+--------+-------------+-----------+-------------+-----------+ 

mysql.user

Code: Select all

+-----------+-------------+-----------+
| User      | Create_priv | Drop_priv |
+-----------+-------------+-----------+
| test-user |             |           |
+-----------+-------------+-----------+

Verhalten ändert sich nicht -> der User kann nach wie vor seine DB löschen.

PS: Dann ist das was im MySQL Manual steht Quatsch:

CREATE Enables use of CREATE TABLE

Der User kann damit auch DB's erstellen - auch wenn es nur jene sind, auf die er Zugriff hat. Er soll aber selbst das nicht können.

[Joe User]

Habe ich bereits gelesen ... jetzt das 5te Mal. Kann mir mal bitte jemand virtuell das 4-Kant drüber ziehen? Schläge auf den Hinterkopf sollen ja helfen ...

Code: Select all

 GRANT CREATE,DROP ON `test-user01`.* TO `test-user`@`mysql4`

"Gut, machste mal" denk ich mir -> führt zum gleichen Ergebnis wie vorher: der User kann die DB löschen.

s/GRANT/REVOKE/ ;)
Mit GRANT vergibst Du dem User Rechte, mit REVOKE nimmst Du sie ihm...

[djcrackman]

@Joe So groß ist das 4-Kant auch wieder nicht :D.

Sobald ich dem User Create und Drop per mysql.db wegnehme, kann er auch keine Tabellen mehr erstellen ... oder hab ich was verpasst?

Ist das 4-Kant größer als ich dachte? 8O

[Joe User]

Du musst dem User per REVOKE die Priviligien CREATE und DROP nehmen, sonst fällt das 4-Kant nicht. Beim Anlegen neuer User musst Du per GRANT jedes erlaubte Privileg einzeln angeben, also nicht

Code: Select all

GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost' IDENTIFIED BY 'DbPaSs';

sondern

Code: Select all

GRANT ALTER,DELETE,INDEX,INSERT,SELECT,UPDATE ON dbname.* TO 'dbuser'@'localhost' IDENTIFIED BY 'DbPaSs';

[djcrackman]

@joe Wie ich bereits sagte, dann kann der User keine Tabellen mehr anlegen/löschen. Das soll er aber nach wie vor können.

CREATE command denied to user 'test-user'@'mysql4' for table 'test'

Zur Info: MySQL 5.0.22

[djcrackman]

Man verzeihe mir den Doppelpost ...

Ich habe nun eine Lösung gefunden:

mysql.db

Code: Select all

+--------+-------------+-----------+-------------+-----------+
| Host   | Db          | User      | Create_priv | Drop_priv |
+--------+-------------+-----------+-------------+-----------+
| mysql4 | test-user01 | test-user | N           | N         |
| mysql4 | test-user02 | test-user | N           | N         |
| mysql4 | test-user03 | test-user | N           | N         |
| mysql4 | test-user04 | test-user | N           | N         |
| mysql4 | test-user05 | test-user | N           | N         |
+--------+-------------+-----------+-------------+-----------+ 

mysql.user

Code: Select all

+--------+-----------+-------------+-----------+
| host   | User      | Create_priv | Drop_priv |
+--------+-----------+-------------+-----------+
| mysql4 | test-user | N           | N         |
+--------+-----------+-------------+-----------+

mysql.tables_priv

Code: Select all

+------+-------------+-------------+------------+------------+
| Host | Db          | User        | Table_name | Table_priv |
+------+-------------+-------------+------------+------------+
| %    | test-user01 | test-user   | test       | Create     |
+------+-------------+-------------+------------+------------+

Gut, das funktioniert nun mit der Tabelle test-user01.test.

Folgendes gibt mir nun zu denken:

The Db, Table_name, and Column_name columns cannot contain wildcards or be blank.

Quelle

WTF?! Gut, was nun? Kann ja kaum meine tables_priv mit einem Wörterbuch aufblasen ...

Noch irgendjemand einen Vorschlag? Ansonsten kann ich mir meine Idee wohl an Glatze kleben ...

[lucki2]

Ich glaube das Brett oder bzw warum mir das Problem so nicht unterkommt ist folgendes:

Wenn $user alle Tabellen einer Datenbank droppen kann ist es irrelevant ob er dann auch noch die Datenbank dazu platt machen kann. Die ist praktisch platt.
Wichtig ist, daß er keine andere DB platt machen kann oder anlegen.
Bzw wenn er das nicht können soll, darf er Tabellen auch nicht droppen können.

[djcrackman]

Die ist praktisch platt.

Na das ist ja mal ein netter Blödsinn ... schon mal darüber nachgedacht, dass es Systeme gibt, wo User DB's droppen, danach neu erstellen und keinen Plan haben, was Dinge wie Character-Set bedeuten?

Davon abgesehen: Ich betreibe eine externe Statusüberwachung, welche DB aktiv ist und welche nicht. Mit diesem Tool kann man die Datenbanken mit einem Klick löschen und die Datenbanken mit einem Klick (mit den korrekten Settings) neu erstellen.

Es gibt Situationen, da muss man User zu Ihrem Glück zwingen -> support mal über 8.000 User, wenn am Tag gut 100 den selben Fehler machen.

[lucki2]

Dann dürften die user auch keine Tabellen, Indexe,Zähler... löschen. Da hast Du sonst die gleichen Probleme - insbesonderes charset.

Und nö ich habe keine user die an MySQL rumspielen dürfen. Höchstens Schreibkräfte, die Accessfrontends vorgesetzt bekommen. :D

[djcrackman]

Du hast nicht gelesen was ich bisher alles gepostet habe, hm ?!

[lucki2]

@joe Wie ich bereits sagte, dann kann der User keine Tabellen mehr anlegen/löschen. Das soll er aber nach wie vor können.

das habe ich gelesen!

[djcrackman]

Den Post auch?

Ich habe nun eine Lösung gefunden:

Leider war es nicht das, was ich brauche.

[lucki2]

Erinner Dich an die Datenbank Vorlesung. Think: DB-Shema.

Das "normale" ist, daß Du Verantwortlichkeiten(Rollen) festlegst. Für Datenbanken(und vielleicht auch für Tabellen). Der Verantwortliche für die Datenbank(Shema) ist der, der Tabellen löschen und erstellen kann, der darf Schema Ändern. Vielleicht hast Du dann noch jemand spezial, der für eine oder zwei Tabellen eine Verantwortlichkeit bekommt: das kannst Du auch festlegen.

Wer Shema nicht ändern darf, darf für die Tabellen auch kein drop und create machen, sondern höchstens alle Datensätze löschen und einfügen. Das wäre dann eine Verantwortlichkeit für den Inhalt der Datenbank aber Shema Änderung entzogen. Gerade Löschen wird normalen usern dann auch noch oft entzogen, weil das constraints bricht. Prinzipiell werden Datensätze nie gelöscht, sondern als veralted markiert(ok. ein bischen puristisch: mir schon klar aber erstmal mit der puristik anfangen und dann aufweichen, wie nötig) .

Was ich meine: Das was Du willst, ist imho nicht üblich. Bzw ist nicht das, wie Datenbank üblicherweise betrachted werden.

Praktisch ist das Ergebnis doch: $user kann einfach auf Tabelle charset oder Engine festlegen und hat alles unterwandert, was Du verhindern wolltest.

Deine Lösung ist der Sonderfall user ist Shemaoperator für wenige Tabellen. Geht, aber es überrascht mich nicht, daß das für alle Tabellen zu einem Spießrutenlauf wird.

[NB: Ich frage mich, ob $user eine DB Normalisieren kann, der den Rest nicht gebacken bekommt]

[djcrackman]

Zur Aufklärung - ich betreibe ein free Webspace Projekt, welches als Konzepthintergrund die Basis hat, dass der User größt mögliche Entscheidungskraft und Verantwortung hat.

Meine User dürfen beispielsweiße auch Dinge wie safe_made und register_globals selbst verwalten -> wer seinen Content damit gefährdet, der ist selbst schuld kann sich sein 'Der ISP hats verbockt' an den Hut stecken.

[lucki2]

Dann würde ich auch analoges für die DB vorschlagen, weil: wer seine DB verbockt soll sich einlesen. Für Dich ist wichtig, daß die sich gegenseitig nicht in die Quere kommen. Und das ist ja gegeben. Datenbank backup und restore wirst Du zulassen wollen und dann braucht der User die Rechte dazu.

Imho ist es sogar überhaupt nicht möglich, was Du willst. Weil Du dem user explizites drop und create für Tabellen geben müßtest, von denen Du noch gar nicht weißt, daß sie irgendwann existieren werden.
[PS Edits sind nur Meine Rechtschreibschwäche, für die Leser etwas erträglicher gemacht ;) ]