Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23875

select into outfile not respect UMASK and UMASK_DIR

Details

    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.

      Attachments

        Issue Links

          Activity

            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.
            assen.totin 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.

            MySQL simply changed the hardcoded 0666 to hardcoded 0640

            serg Sergei Golubchik added a comment - MySQL simply changed the hardcoded 0666 to hardcoded 0640
            serg 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

            serg 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 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

            serg 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

            or 644 indeed

            serg Sergei Golubchik added a comment - or 644 indeed
            rucha174 Rucha Deodhar added a comment - patch: https://github.com/MariaDB/server/commit/dbb2938a73b86f6df080786da0f2c9b104470352

            ok to push

            serg Sergei Golubchik added a comment - ok to push

            People

              rucha174 Rucha Deodhar
              Richard Richard Stracke
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.