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:
Category:MySQL Server: Options Severity:S3 (Non-critical)
Version:8.0, 8.0.21 OS:Debian (10)
Assigned to: CPU Architecture:x86

[30 Jul 2020 15:47] Sven Heinemann
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"
[31 Jul 2020 6:41] MySQL Verification Team
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
[root@ol8 Downloads]# rpm -qa|grep -i mysql|grep -v grep
[root@ol8 Downloads]# 

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.

[1 Aug 2020 9:56] Sven Heinemann
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
ft-min-word-len = 3
ft-max-word-len = 64
myisam-recover-options = BACKUP,FORCE

No other files are included.
[1 Aug 2020 10:01] Sven Heinemann
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
[1 Aug 2020 10:32] MySQL Verification Team
Thank you Sven, for the details.
Verified as described.

[1 Aug 2020 10:32] MySQL Verification Team
MySQL Server 8.0.21 test results

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

[3 Aug 2020 11:07] Georgi Kodinov
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
[3 Aug 2020 11:24] Sven Heinemann
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.
[3 Aug 2020 17:36] Sven Heinemann
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.
[24 Nov 2020 18:06] Paul DuBois
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