Unterbinden von Load_file() in Mysql und MariaDB

Sonntag, 17. Februar, 2019

Ich benötige zum Betreiben von Applikationen keine Dateizugriffe via Mysql. Wenn es weder Dateien vom Server noch vom Client braucht, fühle ich mich wohler, wenn die Funktion komplett deaktiviert ist, weil das ein offenes Scheunentor sein kann.

Um das Laden von Dateien innerhalb SQL zu vermeiden, gibt es in Mysql die Möglichkeit, in der Konfiguration den Dateizugriff zu unterbinden

[mysqld]
local-infile = 0|1 oder ON|OFF
secure_file_priv = [Wert]

Kurz in der Dokumentation die Werte nachlesen, ins Puppet kippen und auf alle Server verteilen.

Als Test, ob ich erfolgreich bin, dient der Aufruf … dieser muss NULL ausgeben und keinen Dateiinhalt.

#  mysql -e "SELECT  load_file('/etc/passwd');"
+--------------------------+
| load_file('/etc/passwd') |
+--------------------------+
| NULL                     |
+--------------------------+

Das war die Idee. Eigentlich klingt es einfach.
Leider verhalten sich aber die Einstellungen von Mysql und MariaDB unterschiedlich.

Der Wert für local-infile muss bei beiden 0 oder OFF sein. local-infile ist aber eine dynamische Variable - das ist aber lediglich der Startwert, der mit einem SQL Befehl in der laufenden Instanz neu gesetzt werden kann.

Heisst: es braucht zwingend den Wert für secure_file_priv, der sich wiederum NICHT zur Laufzeit verändern lässt.

(1)
Variante für Mysql:

[mysqld]
(...)
local-infile = 0
secure_file_priv = NULL
(...)

Danach einmal den Service neu starten systemctl restart mysql … dann habe ich das Verhalten wie in meinem Testaufruf.
Dieses Setup funktioniert nicht auf MariaDB - es wird mit einem Fehler in der Variable secure_file_priv beendet.

Die Dokumentation sagt: wenn secure_file_priv fehlt, würde der Dateizugriff verhindert werden…

Description: LOAD DATA, SELECT … INTO and LOAD FILE() will only work with files in the specified path. If not set, the default, the statements will work with any files that can be accessed.

Aber das ist nicht korrekt! Wenn ich secure_file_priv nicht setze, und es aus der laufenden Datenbank abfrage, ist der Wert leer

# mysql -e "SHOW VARIABLES LIKE 'secure_file_priv';"
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| secure_file_priv |            |
+------------------+------------+

… und ein SELECT load_file(’/etc/passwd’); zeigt mir den Dateiinhalt an!
Wer Percona oder einen anderen Mysql-Abkömmling verwendet, sollte das Verhalten austesten.

MariaDB erwartet einen existierenden Verzeichnisnamen. Ich habe mich entschieden, /dev/null zu nehmen, weil es sowohl existiert als auch ein User hier keine Datei ablegen kann:

(2)
Variante für MariaDB:

[mysqld]
(...)
local-infile = 0
secure_file_priv = /dev/null
(...)

(3)
Bliebe noch die Software-Verteilung… wenn in Puppet die Mysql-Klasse aufgerufen wird, muss diese von irgendwoher wissen, ob das Produkt am Zielsystem MariaDB oder Mysql ist. Die Lazy Variante wäre, auf das OS zu reagieren, weil Defaults in den Repos beispielsweise von Debian oder CentOS sich unterscheiden. Besser und sicherer ist natürlich ein echtes Flag.

Update zu (3):

Meine Variante für ein vom Mysql Daemon nicht verwendbares, aber stets existierendes Verzeichnis für beide Mysql-Varianten ist … “/root”

[mysqld]
(...)
local-infile = 0
secure_file_priv = /root
(...)

weiterführende Links:

  1. Golem: Lange bekannte MySQL-Lücke führt zu Angriffen (27.1.2019)
  2. secure_file_priv - mysql - Docs (en)
  3. secure_file_priv - mariaDB - Docs (en)

Datenbank-Optimierung - mein Highlight der Woche

Sonntag, 18. Februar, 2018

Bei meiner Arbeit an der Uni Bern war ein Grossteil der Zeit in die Optimierung von Datenbank-Zugriffen geflossen. Das betraf hauptsächlich ein System für ein Portal für Dozierende und Studierende mit Stundenplänen, Kurseinschreibungen, Feeds zu etlichen Themen und nach Studienjahr getrennt, Kalendersynchronisation von personalisierten Kalendern uvm. Jenes Portal ist uralt und wurde einmal mit PHP4 entwickelt und sollte abgelöst werden. Wurde es aber nicht, sondern es wurde vor vielen Jahren mühsam unter PHP5 lauffähig gemacht, aber der Code blieb noch immer zumeist prozedural, mit vielen Includes und gespickt mit allen erdenklichen Highlights an Programmiersünden, sei es Wartbarkeit, Caching/ Performance, SQL-Injection oder Verständnis von Algorithmen und Gestaltung von Datenbankabfragen. Seit dem ersten Ablösetermin sind nun 8..9 Jahre vergangen … aber Herbst 2019 wird es endlich(!!) abgelöst. Heisst aber: bis dahin muss es weiter am Leben erhalten werden.

Es wurden 5 Applikationsteile, die “am meisten weh tun” ausgemacht und jene optimiert. Letzten Dienstag wurde es eingespielt. Doch, es hat sich gelohnt - da ist so ein markanter Abfall:

2018-02-18-dbperformance-queries-by-week.png

Man könnte meinen: da ist was kaputt. Aber nein: es funktioniert genau gleich!!
Ich hoffe, ich kann euch mit diesem Praxis-Beispiel motivieren: macht einmal eine Performance-Analyse und schaut genauer auf die Top 3!

[Weiterlesen…]

Mysql-connect sehr langsam?

Mittwoch, 28. August, 2013

Für Windows gibt es fixfertige Pakete für die Kombination Apache + Php + Mysql + X, wie z.B. XAMPP oder Wamp.

Für ein kleines Projekt habe ich auf eine solche zurückgegriffen und irgendwie war es langsam. Was genau langsam war, war nach einigem Debugging lokalisiert:

(...)
$iStart=microtime(true);
mysql_connect($hostname . ":" . $hostport, $username, $password);
echo microtime(true) - $iStart."s to open DB $database<br>";
(...)

Das mysql_connect() brauchte regelmässig 1 Sekunde - die anschliessenden Queries 0.00x Sekunden.

Ursache ist der Zugriff mit dem Hostnamen “localhost” auf die Loopback-Adresse. Wenn man den Mysql-Service auf eine IP-Adresse bindet, geht es massiv schneller. Konfiguriert wird dies in der my.ini im Installationsverzeichnis von Mysql. Oder man verbindet sich auf die IP-Adresse 127.0.0.1.
Ach, und unter Windows den Eintrag lower_case_table_names=2 nicht vergessen - daher schiebe ich es mal hinterher:

(...)
bind-address="127.0.0.1"
bind-address = ::1          # fuer ipv6
lower_case_table_names=2 
(...)

Nach Änderung der Konfiguration muss man den Mysql-Dienst neu starten, damit es wirksam wird.

Weiterführende Links:

PHP mit Sqlite - mein erster Gehversuch

Donnerstag, 28. Oktober, 2010

Ich habe mal einen Download-Zähler gebaut: mittels .htaccess werden alle Dateizugriffe auf ein PHP-Skript umgebogen, welches einmal die angeforderte Datei ausliefert und den Zugriff protokolliert.

In PHP5 ist Sqlite direkt mitgeliefert. Die Sqlite Datenbank ist eine Textdatei, auf die ohne einen laufenden Server zugegriffen wird. Für kleine Webauftritte, wo das Webroot nicht auf einem NFS- oder SMB-Share liegt, ist dies problemlos.

Der wesentliche Vorteil einer SQl-Datenbank zu einer (CSV-) Textdatei ist die Auswertung der Daten: mit SQL Queries kommt man schnell zu den gewünschten Informationen.

Ich definiere mal in PHP eine Variable mit dem Dateinamen zur Datenbank:

$sqliteDB = $_SERVER['DOCUMENT_ROOT']."/sqlite/downloads.sqlite";

In dieser Datenbank ist - weil es zum Einstieg einfacher ist: mit einem grafischen Tool - eine Tabelle angelegt worden:

CREATE TABLE "downloadcount" (
   "id" INTEGER PRIMARY KEY  AUTOINCREMENT  NOT NULL  UNIQUE ,
  "time" DATETIME,
  "file" TEXT,
  "ext" TEXT,
  "ip" TEXT,
  "referrer" TEXT,
  "usaeragent" TEXT
)

Dann muss man nur noch wissen, welcher Sqlite Treiber beim Provider vorhanden ist. Das kann wahlweise Sqlite2, Sqlite3 oder PDO Sqlite sein. Die Versionen unterscheiden sich bei den Kommandos zum Öffnen der Datenbank oder beim Aufruf zum Ausführen eines Queries.

Bei Sqlite 3

$db = new SQLite3($sqliteDB);

Bei PDO Sqlite 3:

$db = new PDO("sqlite:".$sqliteDB);

Ich beziehe mich mal auf die PDO Variante…
So öffnet man eine DB und fügt mit Ausführung eines SQL Statements einen Eintrag hinzu. Eingefügt werden hier die aktuelle Uhrzeit (des Requests), Dateiname und dessen Erweiterung, IP-Adresse des Aufrufers, Referrer und User-Agent.

// $filename enthält den Dateinamen der heruntergeladenen Datei
$db = new PDO("sqlite:".$sqliteDB);
if ($db) {
  $path_info = pathinfo($filename);
  $ext=$path_info['extension'];

  $sql="INSERT INTO `downloadcount`
    (`time`, `file`, `ext`, `ip`, `referrer`, `useragent`)
    VALUES ('".date("Y-m-d H:i:s")."', '" . $filename . "', '".$ext."', '" . getenv("REMOTE_ADDR") . "',  '" . getenv('HTTP_REFERER') ."','".getenv('HTTP_USER_AGENT')."');
  ";

  // echo "SQL:<br>$sql<br>";
  $db->exec($sql);
}

Weiterführende Links:

HeidiSQL 5 - Mysql-GUI für Windows

Sonntag, 11. April, 2010

HeidiSQL 5 ist eine kostenlose grafische Oberfläche für Mysql-Server. Es ist ein reiner Windows-Client.

Die neue Version 5 von HeidiSQL habe ich mir heute heruntergeladen und habe es als portable Version am Laufen.
Version 4 wollte unter Windows 7 immer das Admin-Passwort haben, warum auch immer (vielleicht hab auch ich das verbockt)…

2010-04-11-heidisql.jpg
[Weiterlesen…]