An manchen Tagen fühle ich mich, als hätte ich von nichts eine Ahnung. So richtig enden will der Umzug noch nicht, da rollt schon die nächste Baustelle auf mich zu: MySQL. In jüngster Zeit komme ich immer mal wieder mit MySQL in Kontakt. MySQL benutzen ist etwas, was ich jetzt seit Jahren nicht mehr getan habe und so manches Detail muß ich mir erst wieder mühsam erarbeiten.

Baerli hatte mir einen Artikel reingedrückt zu MySQL Security. Klar: das kann man vor der Glotze schreiben, GRANT, CREATE USER, DROP USER, SET PASSWORD runterbeten und gut ist. Aber das wollte ich nicht. Also las ich mir ein paar Handbuchseiten durch. Heja, ich habe ja von nichts eine Ahnung…

RENAME

Als erstes stolperte ich über RENAME. MySQL bindet Zugriffsrechte nicht an konkrete SQL-Objekte, sondern an irgendwelche SQL-Objekte, die einen bestimmten Namen haben. MaxDB bindet ein Recht nicht an den Namen sondern an das SQL-Objekt selbst. Wenn man einem MySQL-Anwender Zugriff auf eine Tabelle “mytable” gibt, dann hat er nach einem RENAME TABLE mytable _mytable keinen Zugriff mehr auf das konkrete Objekt, welches seinen Namen von “mytable” auf “_mytable” gewechselt hat. Unter MaxDB hat der Anwender nun Zugriff auf die Tabelle “_mytable”, das Recht wurde transparent übertragen.

Legt man nun unter MySQL eine neue Tabelle “mytable” an, dann hat der Anwender wieder Zugriff auf die neue Tabelle. MaxDB hingegen erkennt, daß es sich um ein anderes Objekt handelt und sperrt den Zugriff.

So einfach und charmant die MySQL-Lösung ist Rechte für Objekte zu vergeben, die einem Namenspattern entsprechen so seltsam ist die Vorstellung, dass jemand mit der Umbenennung von Schemata groben Unfug treiben könnte. Ich empfinde den MaxDB-Weg nach kurzer Eingewöhnung als konsequenter. Aber man gewöhnt sich wohl an alles.

NO_AUTO_CREATE_USER

Wenn ich in der Vergangenheit den Kopf über MaxDB geschüttet habe und genörgelt habe, daß Dinge “halbgar” erscheinen, dann gibt das auch für den SQL-Mode NO_AUTO_CREATE_USER unter MySQL. Der Modus sorgt dafür, dass GRANT keine User anlegt sofern diese kein Passwort mittels IDENTIFIED BY zugewiesen bekommen. Das klang für mich wie eine schlaue Idee, die Cron-Jobs mit SELECT user, host FROM user WHERE password = ” überflüssig machen könnte. Doch meine Hoffnungen wurden arg enttäuscht. Das was ich mir wünschte müsse ja “NO_EMPTY_PASSWORD” heißen und habe nun überhaupt nichts mit NO_AUTO_CREATE_USER zu tun. NO_AUTO_CREATE_USER ist einzig und allein ein “Bugfix” und “Komfortfeature” für GRANT. GRANT gab es vor CREATE USER. Deshalb konnte GRANT dazu benutzt werden User anzulegen auch wenn das vielleicht nicht ganz im Sinne des Wortes “to grant” sein mag. Falls man sich nun bei der Benutzerverwaltung vertippt, dann ist schnell versehentlich ein neuer Benutzer ohne Passwort angelegt anstatt die Rechte eines bestehenden Benutzers zu ändern. Das kann passieren, weil GRANT nicht “to grant” macht sondern mehr macht. Statt nun das GRANT eine Fehlermeldung ausgeben zu lassen, daß man CREATE USER benutzen solle, wurde aufgrund von Abwärtskompatibilität ein Schutz durch die Hintertür eingefügt. GRANT schlägt fehl, wenn der Benutzername unbekannt ist (möglicher Tippfehler) und kein IDENTIFIED BY (oft nicht der Fall bei einfachen GRANT Anweisungen) angegeben ist, sofern NO_AUTO_CREATE_USER gesetzt ist.

Warum GRANT nicht nörgeln kann und auf CREATE USER verweist und kein weiteres Flag NO_EMPTY_PASSWORD eingeführt wurde… Naja, es wird eine Diskussion gegeben haben und leider haben die Leute es bislang immer geschafft mit micht guten Argumenten zu überstimmen, aber schön finden. Aber man gewöhnt sich wohl an alles.

Zwei MySQL-Server auf einem Datenverzeichnis

–skip-privileges ist ein Segen und ein Fluch. Ich empfinde es als Segen. Root-Passwort vergessen? Kein Problem: Datenbank ohne Benutzerprüfungen starten. Nun kann man das natürlich auch als Risiko ansehen, besonders dann wenn jemand Zugriff auf das Binary des Deamon und das Datenverzeichnis hat.

Was hindert mich eigentlich daran einen zweiten MySQL-Server mit dem gleichen Datenverzeichnis zu starten, die Passworte zu verfummeln während der erste MySQL-Server läuft und dann wieder den zweiten MySQL-Server zu stoppen? Etwas kompliziert gedacht, aber so bin ich nun mal. Und natürlich, MyISAM läuft in die Falle. InnoDB erkennt, daß bereits ein Server an den Daten- und Logfiles spielt, aber mit einem –skip-innodb startet der zweite Server und die Änderungen an der MyISAM Datenbank “mysql” gehen schnell von der Hand. Schnell die Accounts verdrehen, zweiten Server stoppen und warten bis der erste Server ein FLUSH PRIVILEGES ausführt.

Ok, die Passworte kann man schnell wieder richten, aber zwei Prozesse auf den gleichen Dateien? MaxDB nörgelt wenigsten rum, wenn man solchen Unsinn versucht. Aber man gewöhnt sich wohl an alles.

… und irgendwann werde ich dann auch verstehen wieso die Dinge so funktionieren wie sie funktionieren. Im ersten Moment ist alles fremd. Wo ist eigentlich die Küche in dieser fremden Wohnung?