MySQL Bugs: #100384: Settings secure-file-priv to NULL results in MySQL creating a /NULL directory

Bug #100384	Settings secure-file-priv to NULL results in MySQL creating a /NULL directory
Submitted:	30 Jul 2020 15:47	Modified:	24 Nov 2020 18:06
Reporter:	Sven Heinemann	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	8.0, 8.0.21	OS:	Debian (10)
Assigned to:		CPU Architecture:	x86

Description:
According to the documentation setting the "secure-file-priv" configuration option to NULL should result in the feature being disabled. Instead, mysqld creates a directory called "NULL" in the root file system on startup.

How to repeat:
Set "secure-file-priv" to NULL in "/etc/my.cnf"

Hello Sven,

Thank you for the report and feedback.
We just tried to reproduce this using Linux - Generic binary tarball build on OL7 and with rpm based installation instance on OL8.

- OL8
[root@ol8 Downloads]# tail -2 /etc/my.cnf
authentication_ldap_simple_auth_method_name=simple
secure-file-priv=NULL
[root@ol8 Downloads]# rpm -qa|grep -i mysql|grep -v grep
mysql-commercial-common-8.0.21-1.1.el8.x86_64
mysql-commercial-client-8.0.21-1.1.el8.x86_64
mysql-commercial-devel-8.0.21-1.1.el8.x86_64
mysql-commercial-libs-8.0.21-1.1.el8.x86_64
mysql-commercial-server-8.0.21-1.1.el8.x86_64
[root@ol8 Downloads]# 

- CLI
mysql> show global variables like '%secure_%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| require_secure_transport | OFF   |
| secure_file_priv         | NULL  |
+--------------------------+-------+
2 rows in set (0.00 sec)

- No "NULL" dir created in / or even in datadir of mysqld instance

[root@ol8 Downloads]# ls -l /|grep NULL
[root@ol8 Downloads]# ls -l /var/lib/mysql|grep NULL
[root@ol8 Downloads]# 

-- Excerpt from error log

cat /var/log/mysqld.log |grep secure-file
2020-07-31T06:06:55.128511Z 0 [Note] [MY-010098] [Server] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled
2020-07-31T06:25:42.358582Z 0 [Note] [MY-010098] [Server] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled
2020-07-31T06:35:01.177627Z 0 [Note] [MY-010098] [Server] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled

This is the behavior we(including Harin) observed:

If we supply NULL, no dir named NULL is created i.e in / or in datadir
If we supply non-existing dir e.g. "haha", server startup complaint and fail.
If we supply "NULL" (not NULL - this is different), server starts. Still we don't see NULL dir anywhere

Could you please tell us exact MySQL version you are using? Is it installed using official apt repository or using binary tarball? Please paste the content of my.cnf as is for our reference and to investigate further. Thank you!

If you can provide more information, feel free to add it to this bug and change the status back to 'Open'.  

Thank you for your interest in MySQL.

regards,
Umesh

Actually I observed this in mysql-community-server. I don't know if that makes any difference. The packages used are those from the official repositories set up by the mysql-apt-config package.

This is everything in the [mysqld] section of my configuration file:
pid-file = /run/mysqld/mysqld.pid
socket = /run/mysqld/mysqld.sock
datadir = /var/lib/mysql
log-error = /var/log/mysql/error.log
log-timestamps = SYSTEM
default-authentication-plugin = mysql_native_password
character-set-filesystem = utf8mb4
secure-file-priv = NULL
wait-timeout = 30
interactive-timeout = 300
ssl = 0
auto-generate-certs = 0
mysqlx = 0
mysqlx-cache-cleaner = 0
persisted-globals-load = 0
skip-name-resolve
skip-networking
ft-min-word-len = 3
ft-max-word-len = 64
myisam-recover-options = BACKUP,FORCE

No other files are included.

Also there is nothing in the logs related to it, just:
2020-08-01T11:58:10.605629+02:00 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.21) starting as process 5547
2020-08-01T11:58:10.628305+02:00 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-08-01T11:58:10.958619+02:00 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2020-08-01T11:58:11.250669+02:00 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.21'  socket: '/run/mysqld/mysqld.sock'  port: 0  MySQL Community Server - GPL.

And then, there's this:
> ls -ld /NULL
drwxrwx--- 2 mysql mysql 4096 Aug  1 11:58 /NULL

Thank you Sven, for the details.
Verified as described.

regards,
Umesh

MySQL Server 8.0.21 test results

Attachment: 100384_Debian10.results.txt (text/plain), 18.85 KiB.

Posted by developer:
 
This is a packaging mistake, not mysqld's !
And this is the offender: https://github.com/mysql/mysql-server/blob/8.0/packaging/deb-in/extra/mysql-helpers#L114

Nice find. That's why I hate bloated startup scripts which do useless things. I already had to create a dummy "server-key.pem" file in /var/lib/mysql to keep it from generating self-signed certs, which mysqld could do on its own if they were needed. I already searched the scripts for any mkdir command, and didn't think it could use something else. In fact, 90% of that script is superfluous.

For the time beeing I fixed this by removing the whole pre-start script from my systemd unit file. I recommend cutting down the script to an absolute minimum, which is initializing the database if none exists. Should anything else be broken, it is most likely due to the user's actions, and the user likely wants to fix that on his own, instead of having some script trying to do whatever it thinks could work.

Posted by developer:
 
Fixed in 8.0.23.

Setting the secure_file_priv system variable to NULL should disable
its action, but instead caused the server to create a directory named
NULL.