Bug #53107 secure_file_priv interacts badly with mysql_test_run --mem option
Submitted: 23 Apr 2010 11:37 Modified: 1 Sep 2011 14:41
Reporter: Kristofer Pettersson Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Tests Severity:S3 (Non-critical)
Version:5.1+ OS:Any
Assigned to: Bjørn Munch CPU Architecture:Any

[23 Apr 2010 11:37] Kristofer Pettersson
Description:
Since bug#50737 was patched the --mem option for mysql_test_run will fail if any file is written or read to $MYSQL_TMP_DIR. The reason is that symlinks aren't traversed but rewritten into their true path name. This behavior is assumed intended.

Since these test also usually check that the security restrictions imposed by secure_file_priv also holds, it isn't possible to just lift the restriction by adding an extra --mysqld=--secure_file_priv=""

How to repeat:
./mtr main.loadfile --mem

Suggested fix:
The option --secure_file_priv is added by mysql_test_run and if the option value is adjusted so that it holds the same value as the new tmp path set by --mem the tests should pass again.
[23 Apr 2010 13:08] Kristofer Pettersson
s/loadfile/main.loaddata/
[7 Jun 2010 10:22] Bjørn Munch
I couldn't reproduce this but I just picked it up again and find out it doesn't fail on Solaris (my primary development platform) but it does fail on Linux. What I get is a result diff like this:

---
 Variable_name  Value
-secure_file_priv       MYSQLTEST_VARDIR/
+secure_file_priv       /dev/shm/var_auto_MI45/
 select @@secure_file_priv;
 @@secure_file_priv
-MYSQLTEST_VARDIR/
+/dev/shm/var_auto_MI45/
 set @@secure_file_priv= 0;
---

Before I look deeper into this, I'd like to confirm that this is the error you are referring to?
[10 Feb 2011 12:32] Bjørn Munch
I got no feedback on this, I can't reproduce it on current 5.1 and suspect this has been resolved by other changes? Please close if no longer an issue.
[11 Mar 2011 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".