MySQL Bugs: #4881: RENAME causes Crash/segfault

Bug #4881	RENAME causes Crash/segfault
Submitted:	4 Aug 2004 0:24	Modified:	8 Aug 2004 0:16
Reporter:	Erik Perrohe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	4.1.3-beta	OS:	Linux (Linux/Fedora Core 1)
Assigned to:	Sergei Golubchik	CPU Architecture:	Any

Description:

Attempting to alter/rename a table into another database causes a crash/segfault in the server.

My goal was to restructure some databases.  I wanted to relocate some tables.
The result was a mySQL crash that shutdown a production server, ouch!

How to repeat:
Note: I didn't test this script... (once was enough).  you may have to tweak it. this is an approximation of what I did.

create database testdb1;
create database testdb2;
 
use testdb1;
create table foo (id INT AUTO_INCREMENT PRIMARY KEY) TYPE=MyISAM;
insert into foo (id) values(NULL);

-- crash happens here
alter table foo rename to testdb2.foo2

-- naturally rename works fine if you don't specify a database
-- and  create table testdb2.foo2 select from foo   also works fine

-- I was logged in as root so permissions was not a factor

-- Result
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

Segmentation fault

Suggested fix:
This has serious DoS possibilities...

might be related to Bug #3478
http://bugs.mysql.com/bug.php?id=3478&files=1

It would be nice to have this ability.  but if that's too difficult then mysql should at least generate an error message.

Hi,

Thank you for your bug report!

I was unable to repeat this on a RH 9 box Linux booty 2.4.21 #12 SMP Thu Aug 14 00:49:40 EDT 
2003 i686 i686 i386 GNU/Linux.

This ends up being very simple filesystem mv commands for MyISAM tables.  The mv is done by 
the user mysqld is running as.  Could it be filesystem issues, permission or otherwise?

In the event of permission problems the server still should not crash.  Are you able to repeat this 
on a similar machine?

Best Regards

I was able to repeat this crash on RH 9 by doing the following:

create database testdb1;
create database testdb2;
 
use testdb1;
create table foo (id INT AUTO_INCREMENT PRIMARY KEY) TYPE=MyISAM;
insert into foo (id) values(NULL);

system sudo chown root.root /usr/local/mydata/testdb2

-- crash happens here
alter table foo rename to testdb2.foo2;

A little bit more about the RH 9 box I verified it on:

uname -a
Linux booty 2.4.21 #12 SMP Thu Aug 14 00:49:40 EDT 2003 i686 i686 i386 GNU/Linux

I've already moved the tables and deleted the original database, so can not verify the permissions.  I did find one other db directory that was accidentally owned by root, I am very glad that you pointed out this error.  

I will have to set up a test server before I can verify if this repros for me as non-root....

However, the original database was in active use by non-privledged clients and the server runs as mysql.

If this does only repro as root then that lowers the priority of the bug since it would no longer be a normal use scenario.

I'll fix the problem reported by MattL (the root stuff).

For the record, this does not happen in 4.0.20.

I have confirmed that the crash only happens when the server lacks write permission to the target database folder.

The scenario in which this occurs is when databases are being copied/created externally from the mysql server.  and one does not happen to be paying attention to the resulting permissions -- oops  :-)

So moving a table from one database to another does work as long as the permissions are correct.  Though I do wonder about such things as symlinks and nfs...

Thanks a lot for testing. This bug was introduced in 4.1.3, and we have found the reason and are working on fixing it for 4.1.4 hopefully.

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

fixed in 4.1.4