Second, using a MariaDB configuration variable will be much better, because:
It will be clear where and when it is set.
It will not require root privileges to add/modify permanently (while the env var will have to reside in the systemd unit file which requires root privileges to edit).
Most importantly, it may then be changed for each session via the SET SQL command.
Assen Totin (Inactive)
added a comment - I disagree about UMASK and UMASK_DIR environment variables.
First, these are not masks, but file creation modes, which is quite confusing and bad.
https://jira.mariadb.org/browse/MDEV-23058?focusedCommentId=158790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-158790
Second, using a MariaDB configuration variable will be much better, because:
It will be clear where and when it is set.
It will not require root privileges to add/modify permanently (while the env var will have to reside in the systemd unit file which requires root privileges to edit).
Most importantly, it may then be changed for each session via the SET SQL command.
Supposedly the server always used 0666 (at least since MySQL 3.20.13, March 1997) because mysqld is normally running under mysql:mysql, so unless files are 0666 they won't be of much use.
Which is very different from UMASK, that sets the mode for table and frm files — files that should not be readable outside of mysql:mysql
Sergei Golubchik
added a comment - - edited Supposedly the server always used 0666 (at least since MySQL 3.20.13, March 1997) because mysqld is normally running under mysql:mysql, so unless files are 0666 they won't be of much use.
Which is very different from UMASK, that sets the mode for table and frm files — files that should not be readable outside of mysql:mysql
The main issue with the 666 mode is the last digit. Security auditors are quite unhappy with world-writable files. If making this configurable is not an option right now, at least change the mode to 644 - it will still let anybody consume the file while not letting it change it.
Assen Totin (Inactive)
added a comment - The main issue with the 666 mode is the last digit. Security auditors are quite unhappy with world-writable files. If making this configurable is not an option right now, at least change the mode to 644 - it will still let anybody consume the file while not letting it change it.
So, changing to 0640 makes absolutely no sense to me. Using UMASK makes no sense either.
New umask server variable does, but it really seems an overkill here. One can simply create a new directory and let the server write there.
The small change that I think we, probably, should do still is to change 0666 to 0664
Sergei Golubchik
added a comment - So, changing to 0640 makes absolutely no sense to me. Using UMASK makes no sense either.
New umask server variable does, but it really seems an overkill here. One can simply create a new directory and let the server write there.
The small change that I think we, probably, should do still is to change 0666 to 0664
Critical MDEV-15844 Add umask and umask_dir as server variable
MDEV-23058 UMASK and UMASK_DIR are modes, not umasks
I disagree about UMASK and UMASK_DIR environment variables.
First, these are not masks, but file creation modes, which is quite confusing and bad.
https://jira.mariadb.org/browse/MDEV-23058?focusedCommentId=158790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-158790
Second, using a MariaDB configuration variable will be much better, because: