Restrict MySQL file privileges

The fix/etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
secure_file_priv = NULL
local_infile = 0

secure_file_priv = NULL disables file import and export entirely. That is the setting you want unless you have a specific, current need for it.

sudo systemctl restart mysql

Why it matters

The FILE privilege lets an account read and write files as the mysql OS user:

SELECT LOAD_FILE('/etc/passwd');
SELECT '<?php system($_GET[0]); ?>' INTO OUTFILE '/var/www/html/x.php';

That is a SQL injection turning into file disclosure, and then into a web shell if the database user can write anywhere the web server serves. It is the standard escalation path from “SQL injection” to “server compromise”, and it is why keeping FILE away from applications is on this list.

secure_file_priv is the backstop for when a grant is wrong:

Value	Effect
NULL	Import and export disabled entirely — what you want
/some/dir	Restricted to that directory
(empty)	No restriction — anywhere the mysql user can reach

An empty value is the dangerous one, and it was the historical default. Packaged installs generally set it to /var/lib/mysql-files/, which is a reasonable middle ground — but NULL is better if nothing uses it, and on most servers nothing does.

local_infile runs in the direction you don’t expect

LOAD DATA LOCAL INFILE reads a file from the client and sends it to the server. So the obvious reading is “a user could load their own files” — which is not much of a risk, since they’re their own files.

The real attack goes the other way, and it’s worth understanding because it changes what you protect:

A malicious or compromised MySQL server can ask a connecting client to send it any file. The protocol lets the server respond to a query with “send me this path”, and a client with local_infile enabled complies. Point a database admin tool at a rogue server and it will hand over /etc/passwd, or the client’s SSH keys, or the application config — from the machine running the client.

That reframes the control: local_infile = 0 on your server closes your server as a participant in that attack. It does not protect your clients connecting elsewhere — that’s a client-side setting. If you run tooling that connects to databases you don’t control, disable local infile in the client too.

This is why the page is medium and not higher: the server-side setting closes a narrow thing. The secure_file_priv half is the part that protects you.

Verify it worked

Check both against the running server:

SHOW VARIABLES WHERE Variable_name IN ('secure_file_priv','local_infile');

Expect secure_file_priv = NULL (shown as empty in some clients — check carefully, because empty display and NULL mean opposite things here) and local_infile = OFF.

Disambiguate with:

SELECT IF(@@secure_file_priv IS NULL, 'NULL — disabled (good)',
          IF(@@secure_file_priv = '', 'EMPTY — unrestricted (BAD)',
             CONCAT('restricted to ', @@secure_file_priv))) AS status;

That distinction is the single easiest thing to misread on this page.

Find every account that could use it:

SELECT user, host FROM mysql.user WHERE File_priv = 'Y';

Then prove it — as an account with FILE, this must fail:

SELECT LOAD_FILE('/etc/passwd');

Expect NULL or an error, not the file. And:

SELECT 1 INTO OUTFILE '/tmp/test-outfile';

Expect ERROR 1290: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement.

Before you apply this

secure_file_priv = NULL breaks any process that imports or exports files, and those tend to be scheduled rather than interactive — so it breaks at 2am, not while you’re watching.

What actually uses it:

• Bulk import jobs using LOAD DATA INFILE.
• Export or reporting jobs using SELECT ... INTO OUTFILE.
• Some backup and ETL tooling.

Note mysqldump does not use FILE — it reads over the connection, so backups are unaffected. That’s the reassuring part, since backups are the first thing people worry about.

Check before you set it:

SELECT user, host FROM mysql.user WHERE File_priv = 'Y';

If that returns only root-ish admin accounts, NULL is safe. If an application account has FILE, find out why before removing it — and the answer is usually that someone granted ALL and never looked.

If something genuinely needs file import, use a directory rather than reopening it completely:

secure_file_priv = /var/lib/mysql-files/

local_infile = 0 breaks client-side bulk loading, which some ORMs and import tools use for speed. The error names LOCAL explicitly, so it’s at least a diagnosable failure — unlike most things on this page.

Related

• Grant least privilege — don’t grant FILE in the first place.
• MySQL exposed to the internet — where this escalation ends.