[MDEV-23875] select into outfile not respect UMASK and UMASK_DIR Created: 2020-10-02  Updated: 2021-04-19  Resolved: 2020-12-31

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.2.37, 10.3.28, 10.4.18, 10.5.9

Type: Bug Priority: Critical
Reporter: Richard Stracke Assignee: Rucha Deodhar
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Relates
relates to MDEV-15844 Add umask and umask_dir as server var... Needs Feedback
relates to MDEV-23058 UMASK and UMASK_DIR are modes, not um... Closed

 Description   

select into outfile creates files everytime with 666 permission, regardsless if umask environment variables and umask settings on OS level.

It seems hardcoded.

/***************************************************************************
 
** Export of select to textfile
 
***************************************************************************/
 
[..] 
static File create_file(THD *thd, char *path, sql_exchange *exchange,
 
			IO_CACHE *cache)
 
[...]
 
 /* Create the file world readable */
 
  if ((file= mysql_file_create(key_select_to_file,
 
                               path, 0666, O_WRONLY|O_EXCL, MYF(MY_WME))) < 0)
 
    return file;
 
#ifdef HAVE_FCHMOD
 
  (void) fchmod(file, 0666);			// Because of umask()
 
#else
 
 (void) chmod(path, 0666);
 
#endif

It should use my_umask instead to respect UMASK and UMASK_DIR environment variables.

 Comments   
Comment by Assen Totin (Inactive) [ 2020-10-06 ]

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.
Comment by Sergei Golubchik [ 2020-10-16 ]

MySQL simply changed the hardcoded 0666 to hardcoded 0640

Comment by Sergei Golubchik [ 2020-10-16 ]

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

Comment by Assen Totin (Inactive) [ 2020-10-16 ]

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.

Comment by Sergei Golubchik [ 2020-10-16 ]

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

Comment by Sergei Golubchik [ 2020-10-16 ]

or 644 indeed

Comment by Rucha Deodhar [ 2020-12-29 ]

patch: https://github.com/MariaDB/server/commit/dbb2938a73b86f6df080786da0f2c9b104470352

Comment by Sergei Golubchik [ 2020-12-30 ]

ok to push

Generated at Thu Feb 08 09:25:43 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.