| Bug #39408 | Incorrect path computation for file commands | ||
|---|---|---|---|
| Submitted: | 11 Sep 2008 19:13 | Modified: | 7 Jul 2009 16:08 |
| Reporter: | Mats Kindahl | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S2 (Serious) |
| Version: | 6.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[11 Sep 2008 19:35]
Mats Kindahl
I notice that when pulling from the mysql-6.0-backup clone, the bodies have been switched, so the test is correct in that clone and the first problem mentioned is not present. However, the path is still "cleaned", so that problem remains.
[12 Sep 2008 9:11]
Susanne Ebrecht
Verified as described by reading MySQL 6.0 bzr tree code.
[5 Nov 2008 14:06]
Øystein Grøvlen
The symlink issue is not particular to Backup command. Same issue also exists for SELECT ... INTO OUTFILE.
[7 Jul 2009 16:08]
Chuck Bell
This bug has been fixed in the backup code. The code in question no longer resembles the issue and the problem has been fixed. Note: The reply about SELECT...OUTFILE is unrelated and if a problem exists there a new bug should be created.
Description: When issuing the BACKUP command, the path where the backup should be placed is computed incorrectly in Stream::prepare_path(), causing a valgrind warning for backup_views and also will cause the backup to be placed at an incorrect path. First, there is a test if a path is "hard-coded" (i.e., absolute) that has been negated. A patch to correct this is: --- sql/backup/stream.cc 2008-08-08 17:21:31 +0000 +++ sql/backup/stream.cc 2008-09-11 11:45:59 +0000 @@ -313,7 +313,7 @@ m_path.length(0); m_path.append(new_path); } - else if (!test_if_hard_path(orig_loc.str)) + else if (test_if_hard_path(orig_loc.str)) { /* Case 2: Backup image file name has hard path. Since the test is negated, a relative path name not starting with a dot (e.g., 'foo.bak') will be treated as if it is an absolute path and used directly. This will cause the backup to be placed at the current directory for the executing server, not at an absolute path. Second, If the path is relative and starts with a dot, it is "cleaned" to remove .. directories as in: one/two/../three ---> one/three Unfortunately, this does not work in the presence of soft links: $ ls one/two/../three good place $ ls one/three bad place $ ls -lR .: total 0 drwxr-xr-x 4 mats mats 28 2008-09-11 20:52 elsewhere drwxr-xr-x 3 mats mats 28 2008-09-11 20:52 one ./elsewhere: total 0 drwxr-xr-x 2 mats mats 29 2008-09-11 20:52 three drwxr-xr-x 2 mats mats 6 2008-09-11 20:52 two ./elsewhere/three: total 0 -rw-r--r-- 1 mats mats 0 2008-09-11 20:52 good -rw-r--r-- 1 mats mats 0 2008-09-11 20:52 place ./elsewhere/two: total 0 ./one: total 0 drwxr-xr-x 2 mats mats 28 2008-09-11 20:49 three lrwxrwxrwx 1 mats mats 16 2008-09-11 20:52 two -> ../elsewhere/two ./one/three: total 0 -rw-r--r-- 1 mats mats 0 2008-09-11 20:49 bad -rw-r--r-- 1 mats mats 0 2008-09-11 20:49 place How to repeat: Read the code Suggested fix: There are only two ways to treat the path: either it is absolute or it is relative. If it is absolute, it is used as-is; if it is relative, it is concatenated with the @@global.backupdir.