| Bug #3413 | mysqld: strange interpretation of --defaults-file option | ||
|---|---|---|---|
| Submitted: | 7 Apr 2004 7:42 | Modified: | 28 Apr 2004 19:18 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | 4.0 , 4.1 | OS: | |
| Assigned to: | Michael Widenius | CPU Architecture: | Any |
[7 Apr 2004 8:36]
Matthias Leich
The same strange behaviour will also occur if somebody uses the --defaults-file option in connection with command line tools like 'mysql'. Here may arise a big risk. Let's assume the following szenario: Somebody starts such a tool and expects!! that he affects the database assigned by the defaults-file option. But if he makes my small typo in the filename, he will will affect the database running in <source-distribution>/var, listening on port:3306 ... If that database is the important production database, he is able to produce expensive damages (DROP TABLE, DELETE ..).
[27 Apr 2004 8:51]
Michael Widenius
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:
I don't think it's 100 % safe to do this in 4.0 as some users may depend on the old behaviour. The orginal idea was just that --defaults-file would be a rename of the original option file and in this context the old behaviour was ok.
I have however in 4.1 changed this so that if you use --defaults-file, the given option file must exists.
The fix will be in 4.1.2
Description: mysqld's interpretation of the --defaults-file=<configuration file> does not meet my expectations, when the <configuration file> does not exist. 1. I would expect that the start fails with a message like <configuration file> does not exist ... abort 2. mysqld tries to start a database sitting in <source-distribution>/var. It might be successful to start this database, but this is a action not intended by the writer of the start statement and the help message of mysqld mentions: --defaults-file=# Only read default options from the given file # !!!! The not intended start of that database consumes/uses/locks resources (ports,memory,database container files) and can prevent the daily operation of other important databases. BTW: The files /etc/my.cnf <source-distribution/var/my.cnf ~/.my.cnf do not exist on my box. How to repeat: Please create three databases ONE DATADIR=<source-distribution/var - no DATADIR/my.cnf Assume this database was created for test purposes direct after the installation of MySQL. Actually nobody uses or needs this database. Somebody forgot to delete that database. TWO DATADIR=<somewhere1> - <somewhere1>/my.cnf (port=9350, ...) Assume this database is actually often used for tests. THREE DATADIR=<somewhere2> - <somewhere2>/my.cnf (port=3306, ...) Assume this database is the most important and it should be started in ten minutes. Please try to start TWO with 1. correct start options <source-distribution>/libexec/mysqld --defaults-file=<somewhere1>/my.cnf ----> works good (how expected) 2. stop the database 3. a small typo within the start options <source-distribution>/libexec/mysqld --defaults-file=<not exact file name> ----> databas ONE comes up !!! And now try to start the important database THREE: <source-distribution>/libexec/mysqld --defaults-file=<somewhere2>/my.cnf ----> Can't start server: Bind on TCP/IP port: Address already in use Do you already have another mysqld server running on port: 3306 ? Aborting Suggested fix: I prefer the following solution: If somebody writes a explicit "--defaults-file=<filename>" in the starting option and that file does not exist, mysqld should give an error message and abort.