MySQL Bugs: #21435: test 'trigger' fails on Solaris 10 AMD x86

Bug #21435	test 'trigger' fails on Solaris 10 AMD x86_64
Submitted:	3 Aug 2006 19:46	Modified:	22 Jun 2007 11:25
Reporter:	Chris Jacobson	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Tests	Severity:	S7 (Test Cases)
Version:	5.0.37, 5.0.24-pro-gpl-log	OS:	Solaris (Solaris 10)
Assigned to:		CPU Architecture:	Any
Tags:	5.0.24-pro-gpl-log, solaris, trigger, x86_64

Description:
Server version          5.0.24-pro-gpl-log
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /tmp/mysql.sock

MySQL test suite fails for test 'trigger' with the following message:

"mysqltest: At line 1056: query 'rename table t1 to t2' succeeded - should have failed with errno 1..."

How to repeat:
To reproduce:

Run mysql-rest-run trigger for mysql 5.0.24 on Solaris 10 AMD 64.

Trying to run mysql-test on a Linux 2.6.17 box. (P4 3.00Ghz system, w/ 512MB RAM)
(Slackware 10.2)  Also getting the same results.

/configure --with-mysqld-user=mysql --with-openssl \
            --with-berkeleydb=/usr --with-berkeleydb-includes=/usr/include \
            --with-berkeleydb-libs=/usr/lib \
            --prefix=/usr/local/mysql --with-extra-charsets=all \
            --with-charset=utf8

make test

...
system_mysql_db_fix            [ pass ]
system_mysql_db_refs           [ pass ]
tablelock                      [ pass ]
temp_table                     [ pass ]
timezone                       [ pass ]
timezone2                      [ pass ]
timezone3                      [ pass ]
timezone_grant                 [ pass ]
trigger-compat                 [ pass ]
trigger-grant                  [ pass ]
trigger-trans                  [ pass ]
trigger                        [ fail ]

Errors are (from /compile/mysql-5.0.24/mysql-test/var/log/mysqltest-time) :
mysqltest: At line 1056: query 'rename table t1 to t2' succeeded - should have failed with errno 1...
(the last lines may be the most important ones)

Aborting: trigger failed in default mode. To continue, re-run with '--force'.

Ending Tests
Shutting-down MySQL daemon

#./mysql-test-run trigger

cat ./var/log/mysqltest.log

has the following results:

CURRENT_TEST: trigger
mysqltest: At line 1056: query 'rename table t1 to t2' succeeded - should have failed with errno 1...

Hi - We have also seen this bug with RHEL4u2:

trigger            [ fail ] 
Errors are (from /usr/local/setup/mysql-max-5.0.22-linux-i686-glibc23/mysql- test/var/log/mysqltest-time) : 
mysqltest: At line 1062: query 'rename table t1 to t2' succeeded - should have failed with errno 1... 

Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
mysql-max-5.0.22-linux-i686-glibc23

Is this bug a duplicate of Bug 19389?  <a href="http://bugs.mysql.com/bug.php?id=19389">Bug 19389</a>

I have noted on Bug #19389 that this issue was not specific to SuSE linux and linked that bug to this one.  Additionally, that bug report indicates an additional test failure (rpl_rotate_logs) so to separate the issues, I opened this bug report.

It seems that since this report has been opened that more and more people are seeing this same behavior independant of the OS.

Same problem (trigger test failed) with mysql-5.0.24 on "Fedora Core 5".

All reporters:

Do you run your tests as "root" user?

Yes.  When I installed the database and ran the tests, I ran them as root.  I am currently re-running the tests as the 'mysql' user.  I will post my results here when they are complete.

Looks like a duplicate of bug #21883 then. If 'trigger' test will still fail under non-root user, please, reopen this report.

Verified that all tests pass correctly when run as a non-root user.

Everybody:

In general, it is a bad idea to run any server as (Unix/Linux) "root" unless that is absolutely necessary.
The reason is that *if* somebody (internal or external user, by intention or by accident) can get the server to access any file, this access will be done using "root" privileges, bypassing all checks!

There is a reason why the installation of MySQL typically creates a "mysql" user and lets the server run using those privileges.

Example: If some database user has the (database) privileges to let the server send some info to some file, and s/he gives "/etc/passwd" as the target file, then this operation will erase the system's user list  -  if the server runs as (operating system) "root" user.

In view of that risk, the failing "trigger" test is the least of your problems!

In other words: If *any* server process is run using the privileges of the machine's superuser, this opens a security risk - see to avoid that.

Specifically to that "trigger" test:
It assumes that the database server is not running as "root", as it uses the OS privilege mechanism to force the "rename table" to fail.
If the server is run as "root", this approach is bound to fail.

Please understand that I _DO_NOT_ run the server as root.  That would be incredibly idiotic.  It is run as the mysql user.  

When I *installed* the database, I was running as the root user (which is necessary in order to assign the correct permissions to the directories using the INSTALL-BINARY instructions).

Nowhere in my comments did I ever indicate that I was running the server as root, merely that when I ran the *tests* I was running as the root user.

Same happens to me on Fedora Core 5, building from source rpm. I tried with:

mysql-5.0.18-2.1.src.rpm - fails at rpl-logrotate test
mysql-5.0.22-2.1.src.rpm
mysql-5.0.27-1.fc5.src.rpm
mysql-5.0.37-2.fc7.src.rpm

The rest fail the trigger test.

I did manage to build the rpms by bypassing the self tests, but I am not sure if I should install the rpms considering the self tests fail.

All reporters,

Please, try to repeat with a newer version, 5.0.41. Please, run failing tests (if any) individually, using mysql_test_run.pl, as mysql (non-root) user. Inform about the results (just copy and paste the output).

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".