crash while reloading user table for user w/o hostname

Description

GDB Info

#0 __pthread_kill (threadid=<optimized out>, signo=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:62 #1 0x000000000475d0a3 in my_write_core (sig=11) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/mysys/stacktrace.cc:278 #2 0x000000000359acc4 in handle_fatal_signal (sig=11) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/signal_handler.cc:264 #3 <signal handler called> #4 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32 #5 0x00000000036612be in ACL_HOST_AND_IP::has_wildcard (this=0x7f3a76896d10) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_auth_cache.h:78 #6 0x0000000003658f36 in init_check_host () at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_auth_cache.cc:1212 #7 0x000000000365bf6b in acl_reload (thd=0x7f3a58424000) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_auth_cache.cc:2029 #8 0x0000000003660d9f in reload_acl_caches (thd=0x7f3a58424000) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_auth_cache.cc:3363 #9 0x00000000036c4c5a in acl_end_trans_and_close_tables (thd=0x7f3a58424000, rollback_transaction=true, notify_htons=true) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_user_table.cc:641 #10 0x00000000036c51c5 in log_and_commit_acl_ddl (thd=0x7f3a58424000, transactional_tables=true, extra_users=0x0, extra_error=false, write_to_binlog=true, notify_htons=true) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_user_table.cc:745 #11 0x0000000003685c64 in mysql_grant (thd=0x7f3a58424000, db=0x7f3a3af4ab88 "_db1", list=..., rights=327680, revoke_grant=false, is_proxy=false, dynamic_privilege=..., grant_all_current_privileges=false) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/auth/sql_authorization.cc:3153 #12 0x00000000033b6a03 in mysql_execute_command (thd=0x7f3a58424000, first_level=true) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/sql_parse.cc:4521 #13 0x00000000033bc297 in mysql_parse (thd=0x7f3a58424000, parser_state=0x7f3a7cb26c80, update_userstat=false, force_primary_storage_engine=false) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/sql_parse.cc:6076 #14 0x00000000033bfd0d in wsrep_mysql_parse (thd=0x7f3a58424000, rawbuf=0x7f3a3af4a028 "GRANT CREATE TEMPORARY TABLES, EXECUTE ON _db1.* TO _u1@localhost", length=65, parser_state=0x7f3a7cb26c80, update_userstat=false, force_primary_storage_engine=false) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/sql_parse.cc:7263 #15 0x00000000033ae3c9 in dispatch_command (thd=0x7f3a58424000, com_data=0x7f3a7cb28c50, command=COM_QUERY) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/sql_parse.cc:2050 #16 0x00000000033abb85 in do_command (thd=0x7f3a58424000) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/sql_parse.cc:1419 #17 0x000000000358428f in handle_connection (arg=0x7f3a877db680) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/sql/conn_handler/connection_handler_per_thread.cc:311 #18 0x0000000004853dc6 in pfs_spawn_thread (arg=0x7f3a39dbd220) at /mnt/workspace/qa.pxc80.build/BUILD_TYPE/debug/Host/min-xenial-x64/storage/perfschema/pfs.cc:2836 #19 0x00007f3a9dd716ba in start_thread (arg=0x7f3a7cb2a700) at pthread_create.c:333 #20 0x00007f3a9c12541d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Environment

None

Smart Checklist

Activity

Show:

Krunal Bauskar April 11, 2019 at 4:25 AM

Notes on the original bug:

I did some investigation about the said issue but couldn't reproduce it.

(Bug shouldn't be critical as it occurs with sql_log_bin = 0. Not something PXC recommends).

-----------

As pointed in comments above, test-case creates mysql-user named _7 w/o any hostname.

When the mysql.user is re-loaded if reload routine finds any user that doesn't have hostname it assume it as allow_all_host setting and so hostname checks are suppressed in due course. As per the stack trace above even though it found a user w/o hostname, this allow_all_host setting was not disabled. This caused the said assert.

What sequence could cause this setting not to set is unclear. I tried to reproduce it with multiple variations but in all cases, it was found that allow_all_host is set even if one user has hostname = NULL.

Krunal Bauskar April 11, 2019 at 4:14 AM

handle_fatal_signal (sig=11) in ACL_HOST_AND_IP::has_wildcard | sql/auth/sql_auth_cache.h:78

Not a Bug

Details

Assignee

Reporter

Labels

Time tracking

3h 10m logged

Affects versions

Priority

Smart Checklist

Created April 5, 2019 at 5:54 AM
Updated March 6, 2024 at 10:11 PM
Resolved November 27, 2019 at 5:57 AM

Flag notifications