[MDEV-8589] Non-default ENCRYPTION_KEY_ID is ignored upon reading a table Created: 2015-08-09  Updated: 2015-08-25  Resolved: 2015-08-25

Status: Closed
Project: MariaDB Server
Component/s: Encryption, Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.1
Fix Version/s: 10.1.7

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
Sprint: 10.1.7-2

 Description   
  • create a table with ENCRYPTION_KEY_ID=2 (a valid key in the keys file);
  • insert data into the table;
  • restart server with a different keys file, where key 2 is different or is absent at all;
  • try to read the table =>
    it returns the data.

I would expect that the table would not be readable.
Note: maybe I just don't understand how it meant to work, but it does not look right.

Test case

 
-- source include/have_innodb.inc
 
 
 
--echo
 
--echo # Start server with keys2.txt
 
-- let $restart_parameters=--file-key-management-filename=$MYSQL_TEST_DIR/std_data/keys2.txt --plugin-load-add=file_key_management --innodb-encrypt-log
 
-- source include/restart_mysqld.inc
 
 
 
CREATE TABLE t1 (c VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=2;
 
INSERT INTO t1 VALUES ('foobar');
 
 
 
--echo
 
--echo # Restart server with keys3.txt
 
-- let $restart_parameters=--file-key-management-filename=$MYSQL_TEST_DIR/std_data/keys3.txt --plugin-load-add=file_key_management --innodb-encrypt-log
 
-- source include/restart_mysqld.inc
 
 
 
SELECT * FROM t1;
 
 
 
--echo
 
--echo # Old keys file
 
--cat_file $MYSQL_TEST_DIR/std_data/keys2.txt
 
--echo
 
--echo # New keys file
 
--cat_file $MYSQL_TEST_DIR/std_data/keys3.txt
 
 
 
--echo # KEY 2 values are different ^^^^
 
 
 
DROP TABLE t1;

Output

 
# Start server with keys2.txt
 
CREATE TABLE t1 (c VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=2;
 
INSERT INTO t1 VALUES ('foobar');
 
 
 
# Restart server with keys3.txt
 
SELECT * FROM t1;
 
c
 
foobar
 
 
 
# Old keys file
 
1;593E580927F47AB530D3B1237CDEF6D6
 
2;352E42F1B9DB5CB915C3262FE745520A
 
3;CFE065600F5EB57481075C65180C3F8A
 
4;205379930183490D3BECA139BDF4DB5B
 
5;E2D944D5D837A1DCB22FF7FD397892EE
 
6;BAFE99B0BB87F2CD33A6AF26A11F6BD1
 
 
 
# New keys file
 
1;593E580927F47AB530D3B1237CDEF6D6
 
2;E4B00A45BF775B4E07D634EC5CA5912B
 
3;6E35ACB162B29D1FB9E178021DAF16ED
 
4;971A664A88EE0022D408E40BFAB17E79
 
5;C4FF86FD89879380DA97EAC0BA3057B7
 
6;BAFE99B0BB87F2CD33A6AF26A11F6BD1
 
 
 
# KEY 2 values are different ^^^^
 
DROP TABLE t1;



 Comments   
Comment by Jan Lindström (Inactive) [ 2015-08-25 ]

commit bfb6ea02321f963c2b5f5beb333283585d3d1be3
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Fri Aug 14 11:09:06 2015 +0300

MDEV-8589: Non-default ENCRYPTION_KEY_ID is ignored upon reading a table

Analysis: Problem was that when a new tablespace is created a default
encryption info is also created and stored to the tablespace. Later a
new encryption information was created with correct key_id but that
does not affect on IV.

Fix: Push encryption mode and key_id to lower levels and create
correct encryption info when a new tablespace is created.

This fix does not contain test case because, currently incorrect
encryption key causes page corruption and a lot of error messages
to error log causing mtr to fail.

Generated at Thu Feb 08 07:28:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.