| Bug #44798 | MySQL engine crashes when creating stored procedures with execute_priv=N | ||
|---|---|---|---|
| Submitted: | 11 May 2009 17:47 | Modified: | 3 Aug 2009 23:16 |
| Reporter: | Andrew Shoemaker | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Stored Routines | Severity: | S2 (Serious) |
| Version: | 5.0.77-5.0.81, 5.0, 5.1, 6.0 bzr | OS: | Linux (2.6 64bit) |
| Assigned to: | Sergei Glukhov | CPU Architecture: | Any |
| Tags: | crash, create procedure, execute_priv | ||
[11 May 2009 23:43]
MySQL Verification Team
See bug: http://bugs.mysql.com/bug.php?id=44805.
[12 May 2009 8:42]
Sveta Smirnova
Thank you for the report.
Verified as described.
Backtrace from version 5.1:
Thread 1 (process 9601):
#0 0x002ce402 in __kernel_vsyscall ()
#1 0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2 0x085a7579 in my_write_core (sig=11) at stacktrace.c:310
#3 0x0824d392 in handle_segfault (sig=11) at mysqld.cc:2536
#4 <signal handler called>
#5 0x0858c00b in strdup_root (root=0x88799c0, str=0xa5a5a5a5 <Address 0xa5a5a5a5 out of bounds>) at my_alloc.c:398
#6 0x08326efd in acl_insert_user (user=0x8df52c0 "foobar", host=0x8df52b0 "localhost", password=0x86e358a "", password_len=0, ssl_type=SSL_TYPE_NOT_SPECIFIED,
ssl_cipher=0xa5a5a5a5 <Address 0xa5a5a5a5 out of bounds>, x509_issuer=0xa5a5a5a5 <Address 0xa5a5a5a5 out of bounds>, x509_subject=0xa5a5a5a5 <Address 0xa5a5a5a5 out of bounds>, mqh=0x8df4fc0,
privileges=0) at sql_acl.cc:1245
#7 0x0832bc93 in replace_user_table (thd=0x8df37a0, table=0x8dc9020, combo=@0x8df5298, rights=0, revoke_grant=false, can_create_user=true, no_auto_create=false) at sql_acl.cc:2102
#8 0x08330f60 in mysql_routine_grant (thd=0x8df37a0, table_list=0xb73ac1b4, is_proc=true, user_list=@0xb73ac3c8, rights=17039360, revoke_grant=false, no_error=true) at sql_acl.cc:3303
#9 0x08337f0e in sp_grant_privileges (thd=0x8df37a0, sp_db=0x8e28620 "test", sp_name=0x8e28628 "foo1", is_proc=true) at sql_acl.cc:6245
#10 0x082695d2 in mysql_execute_command (thd=0x8df37a0) at sql_parse.cc:4227
#11 0x0826c258 in mysql_parse (thd=0x8df37a0, inBuf=0x8df5178 "CREATE PROCEDURE `foo1`(input_number INT) BEGIN END", length=51, found_semicolon=0xb73ad2fc) at sql_parse.cc:5929
#12 0x0826ce94 in dispatch_command (command=COM_QUERY, thd=0x8df37a0, packet=0x8e24301 "CREATE PROCEDURE `foo1`(input_number INT) BEGIN END", packet_length=51) at sql_parse.cc:1216
#13 0x0826e0b2 in do_command (thd=0x8df37a0) at sql_parse.cc:857
#14 0x0825a831 in handle_one_connection (arg=0x8df37a0) at sql_connect.cc:1115
#15 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#16 0x003b74fe in clone () from /lib/libc.so.6
[12 May 2009 8:43]
Sveta Smirnova
test case
Attachment: bug44798.test (application/octet-stream, text), 918 bytes.
[12 May 2009 10:37]
Sveta Smirnova
Bug #44805 was marked as duplicate of this one.
[2 Jun 2009 8:24]
Kristofer Pettersson
The privilege part is partly initialized by this bison rule:
clear_privileges:
/* Nothing */
{
LEX *lex=Lex;
lex->users_list.empty();
lex->columns.empty();
lex->grant= lex->grant_tot_col= 0;
lex->all_privileges= 0;
lex->select_lex.db= 0;
lex->ssl_type= SSL_TYPE_NOT_SPECIFIED;
lex->ssl_cipher= lex->x509_subject= lex->x509_issuer= 0;
bzero((char *)&(lex->mqh),sizeof(lex->mqh));
}
;
I can be found in rules like:
grant:
GRANT clear_privileges grant_command
{}
;
However, the CREATE PROCEDURE rule has no 'clear_privileges' and the cipher variables remains uninitialized.
One solution might be to add the clear_privileges sub rule, another might be to make the cipher initialization part of the lex constructor.
Just adding
lex->ssl_type= SSL_TYPE_NOT_SPECIFIED;
lex->ssl_cipher= lex->x509_subject= lex->x509_issuer= 0;
before the call to mysql_routine_grant also solved the crash.
[2 Jun 2009 10:45]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/75451 2764 Sergey Glukhov 2009-06-02 Bug#44798 MySQL engine crashes when creating stored procedures with execute_priv=N The crash happens because of uninitialized lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables. The fix is to add initialization of these variables for stored procedures&functions. @ mysql-test/r/sp_notembedded.result test result @ mysql-test/t/sp_notembedded.test test case @ sql/sql_acl.cc The crash happens because of uninitialized lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables. The fix is to add initialization of these variables for stored procedures&functions.
[3 Jun 2009 7:37]
Kristofer Pettersson
Patch meets the minimal-patch-to-fix-the-problem criteria and as such it is approved. I'd like to see a refactoring of the overall design of st_lex variables initialization but as Sergey Gluhov points out it might be out of the scope of a common bug fix.
[3 Jun 2009 13:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/75526 3341 Sergey Glukhov 2009-06-03 Bug#44798 MySQL engine crashes when creating stored procedures with execute_priv=N(for 6.0 only) The crash happens because of uninitialized lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables. The fix is to move initialization code for grant related variables into lex_start() and get rid of the 'clear_privileges' rule in sql_yacc.yy. @ mysql-test/r/sp_notembedded.result test result @ mysql-test/t/sp_notembedded.test test case @ sql/sql_acl.cc removed initialization code for grant related variables @ sql/sql_lex.cc added initialization code for grant related variables @ sql/sql_yacc.yy removed 'clear_privileges' rule
[4 Jun 2009 6:29]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/75579 2764 Sergey Glukhov 2009-06-04 Bug#44798 MySQL engine crashes when creating stored procedures with execute_priv=N The crash happens because of uninitialized lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables. The fix is to add initialization of these variables for stored procedures&functions. @ mysql-test/r/sp_notembedded.result test result @ mysql-test/t/sp_notembedded.test test case @ sql/sql_acl.cc The crash happens because of uninitialized lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables. The fix is to add initialization of these variables for stored procedures&functions.
[4 Jun 2009 7:29]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/75582 3341 Sergey Glukhov 2009-06-04 [merge] Bug#44798 MySQL engine crashes when creating stored procedures with execute_priv=N(for 6.0 only) The crash happens because of uninitialized lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables. The fix is to move initialization code for grant related variables into lex_start() and get rid of the 'clear_privileges' rule in sql_yacc.yy. @ mysql-test/r/sp_notembedded.result test result @ mysql-test/t/sp_notembedded.test test case @ sql/sql_acl.cc removed initialization code for grant related variables @ sql/sql_lex.cc added initialization code for grant related variables @ sql/sql_yacc.yy removed 'clear_privileges' rule
[16 Jun 2009 8:31]
Bugs System
Pushed into 5.0.84 (revid:gkodinov@mysql.com-20090616082753-kwe0l8uoictxhojf) (version source revid:sergey.glukhov@sun.com-20090604052845-846iabwsi4vml458) (merge vers: 5.0.83) (pib:6)
[16 Jun 2009 11:02]
Bugs System
Pushed into 5.1.36 (revid:joro@sun.com-20090616102155-3zhezogudt4uxdyn) (version source revid:sergey.glukhov@sun.com-20090604055423-tf3xc0wnkey5jbbk) (merge vers: 5.1.36) (pib:6)
[17 Jun 2009 19:24]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090616183122-chjzbaa30qopdra9) (version source revid:sergey.glukhov@sun.com-20090604062744-m6bfj8f0o3vqyfze) (merge vers: 6.0.12-alpha) (pib:11)
[3 Aug 2009 23:16]
Paul DuBois
Note in 5.0.84, 5.1.36, 5.4.4 changelogs. The server crashed in an account with the CREATE ROUTINE privilege but not the EXECUTE privilege created a stored procedure.
[26 Aug 2009 13:46]
Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46]
Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48]
Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:32]
Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[11 Mar 2010 18:01]
Paul DuBois
Noted in 5.5.3 changelog.
Description: I experienced a repeatable issue using mysql 5.0.77 and 5.0.81 (community and percona-highperf). If an account is created with the ability to create stored procedures, but not execute them, then the mysql engine will crash. In all instances a new user account with the host and user of the offending client will be created with no privileges in the user account table. In some situations the mysql engine will also exit with a signal 11. I have a very large stack trace output from a debug version, so if you want that please contact me by email. How to repeat: - launch mysql 5.0.81 with a default my.cnf - create a user account with the following permissions Host: % User: foobar Password: *somecraphere Select_priv: Y Insert_priv: Y Update_priv: Y Delete_priv: Y Create_priv: Y Drop_priv: Y Reload_priv: N Shutdown_priv: N Process_priv: N File_priv: N Grant_priv: N References_priv: N Index_priv: Y Alter_priv: Y Show_db_priv: N Super_priv: N Create_tmp_table_priv: Y Lock_tables_priv: Y Execute_priv: N Repl_slave_priv: N Repl_client_priv: N Create_view_priv: N Show_view_priv: N Create_routine_priv: Y Alter_routine_priv: Y Create_user_priv: N ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 Host: % Db: somedb User: foobar Select_priv: Y Insert_priv: Y Update_priv: Y Delete_priv: Y Create_priv: Y Drop_priv: Y Grant_priv: N References_priv: N Index_priv: Y Alter_priv: Y Create_tmp_table_priv: Y Lock_tables_priv: Y Create_view_priv: N Show_view_priv: N Create_routine_priv: Y Alter_routine_priv: Y Execute_priv: N - create database somedb - login as the "foobar" user using the mysql CLI - run following stored procedure CREATE PROCEDURE `foo1`(input_number INT) BEGIN END; - see if engine has crashed - look in mysql.user (using another window logged in as root user) and see if a new unprivileged account was created for localhost.foobar - if nothing happened then just repeat this a few thousand times. It will definitly happen without much effort. Suggested fix: Well it should probably give an error instead of crashing and creating the locked account.