Code review comment for lp:~gl-az/percona-server/BT-23310-bug1218664-5.5

Probably, whic brings us back to the original fix and problem if (is in
schema mysql) {don't enforce} which then allows any user to bypass
enforcement by simply creating a table within mysql schema is their
privs haven't been restricted.

On 9/30/2013 7:49 AM, Laurynas Biveinis wrote:
> Is the upgrade issue resolved if we skip enforcing SE for everything in mysql, including TABLE_CATEGORY_USER tables, as in another reply?
>
>> OK, so on further testing of an in place upgrade of 5.5 to 5.6, it seems that
>> there are system tables that are reporting as TABLE_CATEGORY_USER,
>> specifically, the mysql.user table. Creating a regular end-user table is also
>> of this type. So on running mysql_upgrade with some printing of interesting
>> info from within check_engine() I get lots of errors (many trimmed for
>> brevity):
>> **** check_engine db_name[mysql] table_name[user] category[2]
>> no_substitution[0] enf_engine[1]
>> InnoDB: Error: trying to create a MySQL system table mysql/user of type
>> InnoDB.
>> InnoDB: MySQL system tables must be of the MyISAM type!
>> **** check_engine db_name[mysql] table_name[db] category[2]
>> no_substitution[0] enf_engine[1]
>> InnoDB: Error: trying to create a MySQL system table mysql/db of type InnoDB.
>> InnoDB: MySQL system tables must be of the MyISAM type!
>>
>> Then eventually a server crash:
>> mysqld-debug: /home/glorch/dev/bug1218664/5.6/Percona-
>> Server/sql/sql_error.cc:430: void Diagnostics_area::set_ok_status(ulonglong,
>> ulonglong, const char*): Assertion `! is_set()' failed.
>> 18:14:09 UTC - mysqld got signal 6 ;
>> This could be because you hit a bug. It is also possible that this binary
>> or one of the libraries it was linked against is corrupt, improperly built,
>> or misconfigured. This error can also be caused by malfunctioning hardware.
>> We will try our best to scrape up some info that will hopefully help
>> diagnose the problem, but since we have already crashed,
>> something is definitely wrong and this may fail.
>> Please help us make Percona Server better by reporting any
>> bugs at http://bugs.percona.com/
>>
>> key_buffer_size=8388608
>> read_buffer_size=131072
>> max_used_connections=1
>> max_threads=153
>> thread_count=1
>> connection_count=1
>> It is possible that mysqld could use up to
>> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 69137 K
>> bytes of memory
>> Hope that's ok; if not, decrease some variables in the equation.
>>
>> Thread pointer: 0x3c6e4b0
>> Attempting backtrace. You can use the following information to find out
>> where mysqld died. If you see no messages after this, something went
>> terribly wrong...
>> stack_bottom = 7f0e74456de0 thread_stack 0x40000
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(my_print_stacktrace+0x35)[0xabc4ec]
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(handle_fatal_signal+0x42e)[0x7316b6]
>> /lib64/libpthread.so.0[0x391b00f500]
>> /lib64/libc.so.6(gsignal+0x35)[0x391a8328a5]
>> /lib64/libc.so.6(abort+0x175)[0x391a834085]
>> /lib64/libc.so.6[0x391a82ba1e]
>> /lib64/libc.so.6(__assert_perror_fail+0x0)[0x391a82bae0]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_ZN16Diagnostics_area13set_ok_statusEyyPKc+0x66)[0x7afcde]
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z5my_okP3THDyyPKc+0x4f)[0x7692c0]
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z17mysql_alter_tableP3THDPcS1_P24st
>> _ha_create_informationP10TABLE_LISTP10Alter_infojP8st_orderb+0x2606)[0x85ea4f]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_ZN19Sql_cmd_alter_table7executeEP3THD+0x51e)[0x9a95e4]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_Z21mysql_execute_commandP3THD+0x7e26)[0x7eba9e]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_Z11mysql_parseP3THDPcjP12Parser_state+0x58a)[0x7eed42]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_Z16dispatch_command19enum_server_commandP3THDPcj+0xd04)[0x7e14c4]
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z10do_commandP3THD+0x3ae)[0x7e0385]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_Z24do_handle_one_connectionP3THD+0x1cc)[0x7a7c74]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(handle_one_connection+0x33)[0x7a7742]
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(pfs_spawn_thread+0x159)[0xdad33f]
>> /lib64/libpthread.so.0[0x391b007851]
>> /lib64/libc.so.6(clone+0x6d)[0x391a8e811d]
>>
>>
>> So I am now not sure what to do. I think at a minimum we need to document in
>> our upgrade process that you MUST disable enforce-storage-engine during
>> mysql_upgrade. Interestingly enough, if you enable it before initially
>> creating your db and calling mysql_install_db you will also get a bunch of
>> failures .

--
George O. Lorch III
Software Engineer, Percona
+1-888-401-3401 x542 US/Arizona (GMT -7)
skype: george.ormond.lorch.iii