| Bug #44798 | MySQL engine crashes when creating stored procedures with execute_priv=N | ||
|---|---|---|---|
| Submitted: | 11 May 2009 19:47 | Modified: | 4 Aug 2009 1:16 |
| Reporter: | Andrew Shoemaker | ||
| Status: | Closed | ||
| Category: | Server: SP | Severity: | S2 (Serious) |
| Version: | 5.0.77-5.0.81, 5.0, 5.1, 6.0 bzr | OS: | Linux (2.6 64bit) |
| Assigned to: | Sergey Gluhov | Target Version: | 5.1+ |
| Tags: | crash, create procedure, execute_priv | ||
| Triage: | Triaged: D1 (Critical) / R2 (Low) / E2 (Low) | ||
[12 May 2009 1:43]
Miguel Solorzano
See bug: http://bugs.mysql.com/bug.php?id=44805.
[12 May 2009 10: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 10:43]
Sveta Smirnova
test case
Attachment: bug44798.test (application/octet-stream, text), 918 bytes.
[12 May 2009 12:37]
Sveta Smirnova
Bug #44805 was marked as duplicate of this one.
[2 Jun 2009 10: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 12: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 9: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 15: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 8: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 9: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 10: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 13: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 21: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)
[4 Aug 2009 1: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.
[12 Aug 2009 23:48]
Paul DuBois
Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.
[15 Aug 2009 0:46]
Paul DuBois
Ignore previous comment about 5.4.2.
[26 Aug 2009 15: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 15: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 15: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 18: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)
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.