Bug #50373 | --secure-file-priv="" | ||
---|---|---|---|
Submitted: | 15 Jan 2010 15:30 | Modified: | 18 Jun 2010 1:07 |
Reporter: | Sergei Golubchik | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 5.1, 5.5.99-m3 | OS: | Any |
Assigned to: | Kristofer Pettersson | CPU Architecture: | Any |
Tags: | Security |
[15 Jan 2010 15:30]
Sergei Golubchik
[17 Jan 2010 7:29]
Sveta Smirnova
Thank you for the report. I can not repeat described behavior with current development sources. $./libexec/mysqld --defaults-file=support-files/my-small.cnf --basedir=. --datadir=./data --port=33051 --log-error --socket=/tmp/mysql_ssmirnova.sock --secure-file-priv="/foo" --secure-file-priv="" & [1] 19573 $./bin/mysql --socket=/tmp/mysql_ssmirnova.sock -uroot Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.1.44-debug Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show variables like 'secure%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | secure_auth | OFF | | secure_file_priv | | +------------------+-------+ 2 rows in set (0.00 sec) mysql> \q Bye Which exact version do you use?
[17 Jan 2010 9:07]
Sergei Golubchik
I said that it doesn't work, not that it cannot be set to an empty string. Doesn't work means that the protection is not lifted. The code in the fix for Bug#43913 looks like: 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))) which only works when opt_secure_file_priv == 0. When it's an empty string, it will be expanded and normalized and compared. That means that an empty string does not disable the check. The second bug in this bug fix: it only covers LOAD DATA. With --secure-file-priv="" we have mysql> load data infile '/etc/group' into table t; ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement (which is incorrect, the as explained above), but mysql> select load_file('/etc/group'); ... 1 row in set (0.00 sec) which shows that the opt_secure_file_priv works differently for LOAD_FILE() and LOAD DATA.
[17 Jan 2010 9:24]
Sveta Smirnova
Thank you for the feedback. Verified as described.
[14 Apr 2010 16:09]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/105657 3353 Kristofer Pettersson 2010-04-14 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. @ mysql-test/t/secure_file_priv-master.opt * added test case for bug 50737 @ mysql-test/t/secure_file_priv.test * added test case for bug 50737 @ 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()
[16 Apr 2010 10:29]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/105842 3353 Kristofer Pettersson 2010-04-16 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()
[16 Apr 2010 14:11]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/105887 3352 Kristofer Pettersson 2010-04-16 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()
[20 Apr 2010 14:18]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/106109 3354 Kristofer Pettersson 2010-04-20 Bug#50373 --secure-file-priv="" Correcting a patch misstake. The converted file path is placed in 'buff' not in opt_secure_file_priv. @ mysql-test/r/loaddata.result * Updated test case; Since secure_file_priv now is normalized the previous values are changed. @ sql/mysqld.cc * Fixed patch misstake
[3 May 2010 11:04]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/107176 3365 Kristofer Pettersson 2010-05-03 Bug#50373 --secure-file-priv="" Iterative patch improvement. Previously committed patch caused wrong result on Windows. The previous patch also broke secure_file_priv for symlinks since not all file paths which must be compared against this variable are normalized using the same norm. 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. @ mysql-test/r/loaddata.result * standard behavior for path normalization is to append a separator to the end of the file path. @ sql/item_strfunc.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms. @ sql/mysql_priv.h * Added signature for is_secure_file_path() @ sql/sql_class.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms. @ sql/sql_load.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
[3 May 2010 14:14]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/107201 3365 Kristofer Pettersson 2010-05-03 Bug#50373 --secure-file-priv="" Iterative patch improvement. Previously committed patch caused wrong result on Windows. The previous patch also broke secure_file_priv for symlinks since not all file paths which must be compared against this variable are normalized using the same norm. 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. @ mysql-test/r/loaddata.result * standard behavior for path normalization is to append a separator to the end of the file path. @ sql/item_strfunc.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms. @ sql/mysql_priv.h * Added signature for is_secure_file_path() @ sql/sql_class.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms. @ sql/sql_load.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
[3 May 2010 16:15]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/107217 3365 Kristofer Pettersson 2010-05-03 Bug#50373 --secure-file-priv="" Iterative patch improvement. Previously committed patch caused wrong result on Windows. The previous patch also broke secure_file_priv for symlinks since not all file paths which must be compared against this variable are normalized using the same norm. 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. @ mysql-test/r/loaddata.result * Removed test code which will currently break the much used --mem feature of mtr. @ mysql-test/t/loaddata.test * Removed test code which will currently break the much used --mem feature of mtr. @ sql/item_strfunc.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms. @ sql/mysql_priv.h * Added signature for is_secure_file_path() @ sql/mysqld.cc * New function for checking if a path compatible with the secure path restriction. * Added initialization of the opt_secure_file_priv variable. @ sql/sql_class.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms. @ sql/sql_load.cc * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
[5 May 2010 15:15]
Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:kristofer.pettersson@sun.com-20100503161439-n4uisjixi4kpr9p7) (merge vers: 5.1.47) (pib:16)
[12 May 2010 10:43]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/108102 3021 Alexander Nozdrin 2010-05-12 Post-fix for Bug#50373: sys_vars.secure_file_priv_basic can not be run with mysql-test/var as a symlink any longer.
[12 May 2010 11:14]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/108108 3022 Alexander Nozdrin 2010-05-12 A follow-up for Bug#50373: remove a commented-out part of the loaddata.test.
[28 May 2010 6:07]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:alik@sun.com-20100512111424-3r8186eayf73xtdu) (pib:16)
[28 May 2010 6:35]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:alik@sun.com-20100520134536-art1p9rrcytw602k) (merge vers: 6.0.14-alpha) (pib:16)
[28 May 2010 7:03]
Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:alik@sun.com-20100512111347-lek7yl2qepolmm5y) (merge vers: 5.5.5-m3) (pib:16)
[4 Jun 2010 1:53]
Paul DuBois
Noted in 5.1.47, 5.5.5, 6.0.14 changelogs. Setting --secure-file-priv to the empty string left the value unaffected.
[17 Jun 2010 12:11]
Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 12:59]
Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:39]
Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[29 Mar 2011 6:16]
Magnus Blåudd
The testcase for this bug creates a file named bug50373.txt in the mysql-test directory, i.e outside of the designated var/ directory. This causes problem if that directory is readonly or in case the created file isn't properly removed, subsequent tests may fail.
[29 Mar 2011 6:19]
Magnus Blåudd
Manually removing the bug50373.txt file and running $>./mtr sys_vars.secure_file_priv <snip> sys_vars.secure_file_priv [ fail ] Test ended at 2011-03-29 08:17:05 CURRENT_TEST: sys_vars.secure_file_priv mysqltest: At line 19: command "remove_file" failed with error 1. my_errno=2 Then running again $>./mtr sys_vars.secure_file_priv <snip> sys_vars.secure_file_priv [ fail ] Test ended at 2011-03-29 08:18:41 CURRENT_TEST: sys_vars.secure_file_priv mysqltest: At line 13: query 'SELECT * FROM t1 INTO OUTFILE '$PROTECTED_FILE';' failed: 1086: File '/home/msvensson/mysql/5.5-cluster/mysql-test/var/mysqld.1/data//../../../bug50373.txt' already exists