Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1(EOL)
-
None
Description
- start server with file_key_management plugin and a valid key_management_filename, otherwise default options;
- create an encrypted InnoDB table;
- shutdown the server;
- start server without file_key_management plugin (or with an invalid key_management_filename which is basically the same)
=>
2015-08-09 18:01:14 140240402089824 [ERROR] InnoDB: Tablespace id 7 encrypted but encryption service not available. Can't continue opening tablespace.
|
|
|
2015-08-09 18:01:14 7f8c43598760 InnoDB: Assertion failure in thread 140240402089824 in file ha_innodb.cc line 21140
|
InnoDB: We intentionally generate a memory trap.
|
|
Stack trace from 10.1 afd59b575a75ebbc57f71ce2865fdff85e3e233b |
#3 <signal handler called>
|
#4 0x00007f7ad3829165 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
|
#5 0x00007f7ad382c3e0 in *__GI_abort () at abort.c:92
|
#6 0x00007f7ad655baf0 in ib_logf (level=IB_LOG_LEVEL_FATAL, format=0x7f7ad6c80900 "Tablespace id %ld encrypted but encryption service not available. Can't continue opening tablespace.\n") at 10.1/storage/xtradb/handler/ha_innodb.cc:21140
|
#7 0x00007f7ad67a8801 in fil_read_first_page (data_file=13, one_read_already=0, flags=0x7ffeb27fd0a8, space_id=0x7ffeb27fd0a0, min_flushed_lsn=0x7ffeb27fd098, max_flushed_lsn=0x7ffeb27fd098, crypt_data=0x7ffeb27fd0b8) at 10.1/storage/xtradb/fil/fil0fil.cc:2066
|
#8 0x00007f7ad67abae2 in fil_open_single_table_tablespace (validate=true, fix_dict=true, id=4, flags=0, tablename=0x7f7ab122c478 "test/t1", path_in=0x0) at 10.1/storage/xtradb/fil/fil0fil.cc:3765
|
#9 0x00007f7ad6785da5 in dict_check_tablespaces_and_store_max_id (dict_check=DICT_CHECK_NONE_LOADED) at 10.1/storage/xtradb/dict/dict0load.cc:1171
|
#10 0x00007f7ad66a8656 in innobase_start_or_create_for_mysql () at 10.1/storage/xtradb/srv/srv0start.cc:2592
|
#11 0x00007f7ad653e9d4 in innobase_init (p=0x7f7ad2c2e270) at 10.1/storage/xtradb/handler/ha_innodb.cc:4101
|
#12 0x00007f7ad63cdd56 in ha_initialize_handlerton (plugin=0x7f7ad2d756e8) at 10.1/sql/handler.cc:513
|
#13 0x00007f7ad61b44cc in plugin_initialize (tmp_root=0x7ffeb2801750, plugin=0x7f7ad2d756e8, argc=0x7f7ad7476430, argv=0x7f7ad2c1e6a0, options_only=false) at 10.1/sql/sql_plugin.cc:1407
|
#14 0x00007f7ad61b509e in plugin_init (argc=0x7f7ad7476430, argv=0x7f7ad2c1e6a0, flags=2) at 10.1/sql/sql_plugin.cc:1680
|
#15 0x00007f7ad6097fe4 in init_server_components () at 10.1/sql/mysqld.cc:5160
|
#16 0x00007f7ad6098f7c in mysqld_main (argc=11, argv=0x7f7ad2c1e6a0) at 10.1/sql/mysqld.cc:5717
|
#17 0x00007f7ad608e800 in main (argc=11, argv=0x7ffeb28024a8) at 10.1/sql/main.cc:25
|
I would expect that the table could not be read, but crashing on startup because there is an unreadable user table (not a system table!) seems to be an overkill.
Also,[ documentation|https://mariadb.com/kb/en/mariadb/data-at-rest-encryption/#file_key_management_filename] suggests otherwise:
If the key file can not be read at server startup, for example if the file key is not present, the encryption will not work and encrypted tables will be unreadable.
Attachments
Issue Links
- causes
-
-
- Closed
-
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-