LOAD DATA INFILE : SQLSTATE[HY000]: General error: 13

[AWOHille]

Hallo,

ich benutze zur Webanalytik Piwik. Folgende Meldung bekomme bei der Datenbankfähigkeit angezeigt

Code: Select all

Fehler:
Try #1: LOAD DATA INFILE : SQLSTATE[HY000]: General error: 13 Can't get stat of '/pfad/piwik/tmp/assets/piwik_option-123.csv' (Errcode: 13) 

Der entsprechende Datenbankbenutzer hat das File Recht. Wodurch wird diese Fehlermeldung verursacht?

[Joe User]

PHPs open_basedir aktiv?
Filesystem kaputt?


BTW: Bei einem sicher konfigurierten MySQLd sollte Piwik folgende Fehlermeldung werfen:

Code: Select all

LOAD DATA LOCAL INFILE : SQLSTATE[42000]: Syntax error or access violation: 1148 The used command is not allowed with this MySQL version[42000]

LOAD DATA LOCAL INFILE ist ein Sicherheitsrisiko und sollte nur erlaubt werden, wenn man weiss was man macht.

[AWOHille]

PHPs open_basedir aktiv?

Ja, das war das Problem. Welches Verzeichnis müsste ich dem open_basedir hinzufügen?

LOAD DATA LOCAL INFILE ist ein Sicherheitsrisiko und sollte nur erlaubt werden, wenn man weiss was man macht.

In wie fern könnte dies zu einem Sicherheitsrisiko werden?

[Joe User]

open_basedir würde ich gar nicht verwenden, da es oft mehr Probleme bereitet als es löst. In diesem Fall müsstest Du den Pfad zu Piwik und den Pfad zum mysql-Binary freigeben. Letzteres würde aber auch alle anderen Binaries in dem Pfad freigeben, was den Sinn hinter open_basedir ausser Kraft setzt. Somit kann man auch gleich auf open_basedir verzichten.
Zudem täuscht open_basedir eine nicht existierende Sicherheit vor, da einem Angreifer andere Scriptsprachen wie Perl, Python oder Shell zur Verfügung stehen, welche nicht von open_basedir erfasst werden.


Zum Sicherheitsrisiko verrät die MySQL-Doku schon ein wenig: http://dev.mysql.com/doc/refman/5.5/en/ ... local.html

[jan10001]

Hast du PDO_MYSQL installiert? Wenn nein dann erklärt das die Meldung.

[ddm3ve]

Was hat das mit mit den Client libs zu tun?

LOAD DATA INFILE

ist eine Anweisung an den Mysl Server und der mysqld freift auf die Daten zu.
Piwki betreibe ich selbst störungsfrei nur mit mysqli Client libs.

edit: LOAD DATA LOCAL INFILE geändert, wäre in der tat eine Client Anweisung, TE sprach aber von einer Serveranweisung.

[jan10001]

@ddm3ve
Seine Fehlermeldung bezieht sich auf "LOAD DATA INFILE" nicht auf "LOAD DATA LOCAL INFILE ".
Der PDO_MYSQL Treiber aktiviert "LOAD DATA INFILE". Allerdings war ich vorschnell es läuft ja sonst gäbe es keinen Errcode. :oops:

Ich kann mich auch irren, aber Errcode 13 bedeutet das er die Datei nicht findet. Die Verwendung von absoluten Pfaden könnte Abhilfe schaffen. (Falsche Dateiberechtigungen müsste Errcode 2 sein.)

[ddm3ve]

Du hast nicht Recht aber dazu lies mal das Zitat unten, ich hatte Joe Users Anweisung kopiert.
Wenn ich mir seine Anforderung betrachte liegt der Client und Server offensichtlich auf der gleichen physischen Maschine.
Von der Berechtigung mal abgesehen wäre als der Weg ob LOCAL oder nicht eigentlich egal.

Ändert aber nichts daran, dass ein "aktueller" mit dem Server kompatibler Client die Daten Laden kann.
PDO_MYSQL Teiber sind hier also nicht zwingend erforderlich.

Zu der notwendigen Berechtigung hier:
http://dev.mysql.com/doc/refman/5.1/de/load-data.html

Ich nutze das nicht wirklich oft, daher nur meine Vermutung, bei der Fehlermeldung scheint mir der Benutzer nicht die nötigen Rechte zu haben.
Ich kann mich wage daran erinnern, dass der Benutzer auch Filesystemberehtigungen auf Datenbanseite benötigt. Eventuell verwechsel ich das auch gerade mit Oracle und dem Data Loader (Import Export Tools zum Dumpen der Datenbank).

Kurz aus der Doku zum Punkt LOCAL zitiert:

Das Schlüsselwort LOCAL wird, sofern angegeben, in Bezug auf die Clientseite der Verbindung interpretiert:

Wenn LOCAL angegeben ist, wird die Datei vom Clientprogramm auf dem Clienthost gelesen und an den Server geschickt. Die Datei kann als vollständiger Pfadname angegeben werden, um die exakte Position zu beschreiben. Erfolgt die Angabe als relativer Pfadname, dann wird der Name relativ zum Verzeichnis interpretiert, in dem das Clientprogramm gestartet wurde.

Wird LOCAL nicht angegeben, dann muss die Datei sich auf dem Serverhost befinden und wird direkt vom Server gelesen. Der Server wendet zur Bestimmung der Dateiposition die folgenden Regeln an:

Wenn der Dateiname absolut angegeben wurde, verwendet ihn der Server wie angegeben.

Ist der Dateiname ein relativer Pfadname mit einer oder mehreren am Anfang stehenden Komponenten, dann sucht der Server nach der Datei relativ zum eigenen Datenverzeichnis.

Wird ein Dateiname ohne Komponenten am Anfang übergeben, dann sucht der Server im Datenbankverzeichnis der Standarddatenbank nach der Datei.

Beachten Sie, dass, sofern keine LOCAL-Option angegeben wurde, die Regeln zur Folge haben, dass eine Datei namens ./myfile.txt im Datenverzeichnis des Servers gesucht wird, während die Datei myfile.txt aus dem Datenbankverzeichnis der Standarddatenbank gelesen wird. Ist also beispielsweise db1 die Standarddatenbank, dann liest die folgende LOAD DATA-Anweisung die Datei data.txt aus dem Datenbankverzeichnis für db1 aus, obwohl die Anweisung die Datei explizit in die Datenbank db2 lädt:

Meine Tipp wäre:
Bereite die Daten so vor, dass ein Bulk import möglich ist.
Also ggf. eine insert into .... values (<DATENSAT 1>),(<DATENSAT 2>),(<DATENSAT 3>) usw.
Das ist min. genau so schnell, sofern man wirklich transaktional (InnoDB) arbeitet und hat längst nicht den Sicherheitsnachteil wie LOAD DATA INFILE, wie Joe User anführt.

[ddm3ve]

Nachtrag, bei der Fehlermeldung wäre wichtig zu wissen, welche Rechte gesetzt sind, wie die Infrastruktur aus sieht, Mysqld z.B. auf einem eigenen host, und dann noch die Versionen der Datenbank und Client.

Msql 5.1 hat meiner Erinnerung nach noch einige Bugs. Die Fehlermedlung selbst ist leider nicht zielführend, zu allgemein.

[Joe User]

Piwik benötigt LOAD DATA [LOCAL] INFILE nicht und man sollte es Piwik daher auch nicht erlauben, ebensowenig irgendeiner anderen (Web)App. Das Risiko über diese Funktion ausgespäht und/oder gehackt zu werden, ist viel höher, als der eventuelle Performancegewinn beim Einlesen von CSV-Dateien.

Wer ernsthaft CSV-Dateien regelmässig einlesen muss, der sollte sich dafür einen Wrapper (Script) schreiben und darin die Datensätze als "normale" SQL-Queries (INSERT/UPDATE/REPLACE) dem MySQL-Client verfüttern.