MySQL Bugs: #74712: Wrong security info in LOAD DATA INFILE documentation

Bug #74712	Wrong security info in LOAD DATA INFILE documentation
Submitted:	6 Nov 2014 12:09	Modified:	11 Apr 2017 23:27
Reporter:	Hartmut Holzgraefe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:	Paul DuBois	CPU Architecture:	Any

Description:
The LOAD DATA INFILE SYNTAX manual section <http://dev.mysql.com/doc/refman/5.6/en/load-data.html> says:

"For security reasons, when reading text files located on the server, the files must either reside in the database directory or be readable by all."

This isn't true though, if e.g. putting user "mysql" in group "shadow" I can read /etc/shadow just fine even though its permissions are:

  -rw-r----- 1 root shadow 1408 Nov  6 10:36 /etc/shadow

(so clearly not "readable by all"):
  
  CREATE TABLE shadow(name VARCHAR(100), 
	              hash VARCHAR(100), 
                      d1 bigint, 
                      d2 bigint, 
                      d3 bigint, 
                      d4 bigint, 
                      d5 bigint, 
                      d6 bigint);

  LOAD DATA INFILE '/etc/shadow' 
    INTO TABLE shadow FIELDS TERMINATED BY ':';

  SELECT hash FROM shadow WHERE name = 'tester'\G
  *************************** 1. row ***************************
  hash: $6$eFov[...]
 
Looking at the source I can't find any check for file permissions 
in LOAD DATA INFILE code either.

What I *did* find though was that the LOAD_FILE() function does
check its file argument for S_IROTH (readable to others/all). 

This is in no way related to LOAD DATA INFILE though ...

Looks as the details of these two different LOAD functionalities
got mixed up in the documentation?

How to repeat:
 see above

Suggested fix:
Not sure whether LOAD DATA INFILE should indeed be limited to world-readable files as documented, or whether just the documentation should be fixed to not claim things that are not actually checked for ...

Hello Hartmut,

Thank you for the bug report.

Thanks,
Umesh

Posted by developer:
 
You're right, the information is out of date. Since secure_file_priv was implemented, non-LOCAL LOAD DATA operations are subject to its value.

Revised text:

Non-LOCAL load operations read text files located on the server. For
security reasons, such operations require that you have the FILE
privilege. See . Also, non-LOCAL load operations are subject to the
secure_file_priv system variable setting. If the variable value is a
nonempty directory name, the file to be loaded must be located in
that directory. If the variable value is empty (which is insecure),
the file need only be readable by the server.