MySQL:Fehler beim Löschen der Datenbank (Fehler Nr. 13; Fehler Nr. 17; Fehler Nr. 39)

Schnellkorrektur

Wenn Sie einfach nur die Datenbank löschen wollen, egal was passiert (aber bitte Lesen Sie zuerst den gesamten Beitrag:Der Fehler wurde aus einem bestimmten Grund angegeben , und es könnte wichtig sein zu wissen, was der Grund war!), können Sie:

• finden Sie das Datenverzeichnis mit dem Befehl SHOW VARIABLES WHERE Variablenname LIKE '%datadir%';
• Halten Sie den MySQL-Server an (z. B. service mysql stop oder rcmysqld stop oder ähnlich unter Linux, NET STOP oder über SERVICES.MSC unter Windows)
• gehen Sie zum Datenverzeichnis (hier sollten Sie nachsehen; siehe unten)
• Entfernen Sie das Verzeichnis mit dem gleichen Namen wie die Datenbank
• Starten Sie den MySQL-Server erneut und verbinden Sie sich damit
• Ausführen eines DROP DATABASE
• das ist es!

Gründe für Fehler 13

MySQL hat keine Schreibrechte auf das übergeordnete Verzeichnis, in dem die mydb Ordner befindet.

Überprüfen Sie es mit

ls -la /path/to/data/dir/         # see below on how to discover data dir
ls -la /path/to/data/dir/mydb   

Unter Linux kann dies auch passieren, wenn Sie MySQL- und AppArmor/SELinux-Pakete mischen und anpassen. Was passiert ist, dass AppArmor erwartet, dass mysqld seine Daten in /path/to/data/dir hat , und erlaubt dort vollständiges R/W, aber MySQLd stammt von einer anderen Distribution oder einem anderen Build und speichert seine Daten tatsächlich woanders (zB:/var/lib/mysql5/data/** im Gegensatz zu /var/lib/mysql/** ). Sie sehen also, dass das Verzeichnis richtige Berechtigungen und Eigentumsrechte hat und dennoch gibt es Errno 13, weil apparmor/selinux keinen Zugriff darauf erlaubt.

Um dies zu überprüfen, überprüfen Sie das Systemprotokoll auf Sicherheitsverletzungen, überprüfen Sie die Konfiguration von apparmor/selinux manuell und/oder geben Sie sich als mysql-Benutzer aus und versuchen Sie, in das Basisverzeichnis var zu wechseln, dann cd inkrementell, bis Sie im Zielverzeichnis sind, und führen Sie so etwas aus wie berühre Erdferkel &&rm Erdferkel . Wenn Berechtigungen und Eigentumsrechte übereinstimmen und das Obige dennoch einen Zugriffsfehler ergibt, besteht die Möglichkeit, dass es sich um ein Problem mit dem Sicherheitsframework handelt.

Gründe für Fehler Nr. 39

Dieser Code bedeutet "Verzeichnis nicht leer". Das Verzeichnis enthält einige versteckte Dateien, von denen MySQL nichts weiß. Für nicht versteckte Dateien siehe Errno 17. Die Lösung ist dieselbe.

Gründe für Fehler 17

Dieser Code bedeutet "Datei existiert". Das Verzeichnis enthält eine MySQL-Datei, die MySQL nicht löschen möchte. Solche Dateien könnten durch ein SELECT ... INTO OUTFILE "filename"; erstellt worden sein Befehl, wobei Dateiname hatte keinen Weg. In diesem Fall erstellt der MySQL-Prozess sie in seinem aktuellen Arbeitsverzeichnis, das (getestet auf MySQL 5.6 auf OpenSuSE 12.3) das Datenverzeichnis der Datenbank ist , z.B. /var/lib/mysql/data/namederdatenbank .

Reproduzierbarkeit:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1676
Server version: 5.6.12-log openSUSE package
[ snip ]    

mysql> CREATE DATABASE pippo;
Query OK, 1 row affected (0.00 sec)

mysql> USE pippo;
Database changed
mysql> SELECT version() INTO OUTFILE 'test';
Query OK, 1 row affected (0.00 sec)

mysql> DROP DATABASE pippo;
ERROR 1010 (HY000): Error dropping database (can't rmdir './pippo/', errno: 17)

-- now from another console I delete the "test" file, without closing this connection
-- and just retry. Now it works.

mysql> DROP DATABASE pippo;
Query OK, 0 rows affected (0.00 sec)

Verschieben Sie die Datei(en) nach draußen (oder löschen Sie sie, wenn sie nicht benötigt wird) und versuchen Sie es erneut. Stellen Sie außerdem fest, warum sie überhaupt erstellt wurden – es könnte auf einen Fehler in einer Anwendung hinweisen . Oder noch schlimmer:siehe unten...

UPDATE:Fehler 17 als Exploit-Flag

Dies geschah auf einem Linux-System mit installiertem Wordpress. Leider war der Kunde unter Zeitdruck und ich konnte weder ein Image der Platte erstellen noch eine echte forensische Runde machen - ich habe die ganze Maschine neu installiert und Wordpress wurde dabei aktualisiert, daher kann ich nur sagen, dass ich fast sicher, dass sie es durch dieses Plugin getan haben .

Symptome :das mysql data-Verzeichnis enthielt drei Dateien mit der Erweiterung PHP. Warte, was?!? -- und in den Dateien gab es eine Menge base64-Code, der an base64_decode übergeben wurde , gzuncompress und [eval()][2][code> . Aha . Das waren natürlich nur die ersten Versuche, die erfolglosen. Die Seite war wirklich pwn3d.

mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)