Bug#50373 --secure-file-priv=""

The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the 
--secure-file-priv option.

The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.

It was also intended that setting the option
to an empty string should be equal to 
lifting all previously set restrictions. This
is also fixed by this patch.


sql/mysqld.cc:
  * If --secure_file_option is an empty string then the option variable
    should be unset.
  * opt_secure_file_option should be normalized once when the server starts.
sql/sql_load.cc:
  * moved variable normalization code to fix_paths()

1 files changed, 1 insertions, 3 deletions

diff --git a/sql/sql_load.cc b/sql/sql_load.cc
index ee3b442c83a..869a52325ea 100644
--- a/sql/sql_load.cc
+++ b/sql/sql_load.cc
@@ -350,9 +350,7 @@ int mysql_load(THD *thd,sql_exchange *ex,TABLE_LIST *table_list,
       }
       else if (opt_secure_file_priv)
       {
-        char secure_file_real_path[FN_REFLEN];
-        (void) my_realpath(secure_file_real_path, opt_secure_file_priv, 0);
-        if (strncmp(secure_file_real_path, name, strlen(secure_file_real_path)))
+        if (strncmp(opt_secure_file_priv, name, strlen(opt_secure_file_priv)))
         {
           /* Read only allowed from within dir specified by secure_file_priv */
           my_error(ER_OPTION_PREVENTS_STATEMENT, MYF(0), "--secure-file-priv");