6.1.6 Security Considerations for LOAD DATA LOCAL
LOAD DATA statement loads a data file into a table. The statement can load a file located on the server host, or, if the
LOCAL keyword is specified, on the client host.
LOCAL version of
LOAD DATA has two potential security issues:
LOAD DATA LOCALis an SQL statement, parsing occurs on the server side, and transfer of the file from the client host to the server host is initiated by the MySQL server, which tells the client the file named in the statement. In theory, a patched server could tell the client program to transfer a file of the server's choosing rather than the file named in the statement. Such a server could access any file on the client host to which the client user has read access. (A patched server could in fact reply with a file-transfer request to any statement, not just
LOAD DATA LOCAL, so a more fundamental issue is that clients should not connect to untrusted servers.)
In a Web environment where the clients are connecting from a Web server, a user could use
LOAD DATA LOCALto read any files that the Web server process has read access to (assuming that a user could run any statement against the SQL server). In this environment, the client with respect to the MySQL server actually is the Web server, not a remote program being run by users who connect to the Web server.
To avoid connecting to untrusted servers, clients can establish a secure connection and verify the server identity by connecting using the
--ssl-mode=VERIFY_IDENTITY option and the appropriate CA certificate.
LOAD DATA issues, clients should avoid using
Adminstrators and applications can configure whether to permit local data loading as follows:
On the server side:
local_infilesystem variable controls server-side
LOCALcapability. Depending on the
local_infilesetting, the server refuses or permits local data loading by clients that request local data loading.
local_infileis disabled. To explicitly cause the server to refuse or permit
LOAD DATA LOCALstatements (regardless of how client programs and libraries are configured at build time or runtime), start mysqld with
local_infiledisabled or enabled.
local_infilecan also be set at runtime.
On the client side:
ENABLED_LOCAL_INFILECMake option controls the compiled-in default
LOCALcapability for the MySQL client library (see Section 2.9.7, “MySQL Source-Configuration Options”). Clients that make no explicit arrangements therefore have
LOCALcapability disabled or enabled according to the
ENABLED_LOCAL_INFILEsetting specified at MySQL build time.
By default, the client library in MySQL binary distributions is compiled with
ENABLED_LOCAL_INFILEenabled. If you compile MySQL from source, configure it with
ENABLED_LOCAL_INFILEdisabled or enabled based on whether clients that make no explicit arrangements should have
LOCALcapability disabled or enabled.
For client programs that use the C API, local data loading capability is determined by the default compiled into the MySQL client library. To enable or disable it explicitly, invoke the
mysql_options()C API function to disable or enable the
MYSQL_OPT_LOCAL_INFILEoption. See Section 22.214.171.124, “mysql_options()”.
For the mysql client, local data loading capability is determined by the default compiled into the MySQL client library. To disable or enable it explicitly, use the
If you use
LOAD DATA LOCALin Perl scripts or other programs that read the
[client]group from option files, you can add a
local-infileoption setting to that group. To prevent problems for programs that do not understand this option, specify it using the
In all cases, successful use of a
LOCALload operation by a client also requires that the server permits local loading.
LOCAL capability is disabled, on either the server or client side, a client that attempts to issue a
LOAD DATA LOCAL statement receives the following error message:
ERROR 1148: The used command is not allowed with this MySQL version