Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1.38
-
None
Description
A regression was introduced in 10.1.38. See the following behavior:
MariaDB [db1]> SET GLOBAL innodb_encrypt_tables=OFF;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [db1]> SET SESSION innodb_default_encryption_key_id=2;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [db1]> CREATE TABLE unencrypted_tab (id int primary key);
|
ERROR 1005 (HY000): Can't create table `db1`.`unencrypted_tab` (errno: 140 "Wrong create options")
|
MariaDB [db1]> SHOW WARNINGS;
|
+---------+------+--------------------------------------------------------------------------------+
|
| Level | Code | Message |
|
+---------+------+--------------------------------------------------------------------------------+
|
| Warning | 140 | InnoDB: innodb_encrypt_tables=OFF only allows ENCRYPTION_KEY_ID=1 |
|
| Error | 1005 | Can't create table `db1`.`unencrypted_tab` (errno: 140 "Wrong create options") |
|
| Warning | 1030 | Got error 140 "Wrong create options" from storage engine InnoDB |
|
+---------+------+--------------------------------------------------------------------------------+
|
3 rows in set (0.00 sec)
|
This can be worked around by setting innodb_default_encryption_key_id=1 or ENCRYPTED=NO. See the following:
MariaDB [db1]> SET SESSION innodb_default_encryption_key_id=1;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [db1]> CREATE TABLE unencrypted_tab (id int primary key);
|
Query OK, 0 rows affected (0.01 sec)
|
|
|
MariaDB [db1]> DROP TABLE unencrypted_tab;
|
Query OK, 0 rows affected (0.01 sec)
|
|
|
MariaDB [db1]> SET SESSION innodb_default_encryption_key_id=2;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [db1]> CREATE TABLE unencrypted_tab (id int primary key) ENCRYPTED=NO;
|
Query OK, 0 rows affected (0.01 sec)
|
It seems that this was introduced by the following change:
Attachments
Issue Links
- relates to
-
-
- Open
-
-
-
- Closed
-
Activity
I just discussed this with monty. His idea is that "don’t care" attributes should be ignored, or at most a warning could be issued for them. This allows ALTER TABLE from one storage engine to another while preserving attributes that only matter for some storage engines.
Based on that basic principle, we should ignore the encryption_key_id attribute (whether or not it was explicitly specified by the user, or inherited from the session variable innodb_default_encryption_key_id). We could issue a warning if innodb_default_encryption_key_id is assigned to an invalid value, or an invalid encryption_key_id is being implicitly or explicitly passed to CREATE TABLE or ALTER TABLE.
The problem with encryption_key_id is that it is not being persisted anywhere in InnoDB except if the table attribute encryption is specified and is something else than encryption=default. MDEV-17320 made it a hard error if encryption_key_id is specified to be anything else than 1 in that case.
Ideally, we would always persist encryption_key_id in InnoDB. But, then we would have to be prepared for the case that when encryption is being enabled for a table whose encryption_key_id attribute refers to a non-existing key.
Starting with MariaDB Server 10.2, thanks to MDEV-5800, we could open the table definition from InnoDB side when the encryption is being enabled.
In MariaDB Server 10.1, our best option remains to not store anything inside InnoDB. But, instead of returning the error that MDEV-17320 introduced, we should merely issue a warning that the specified encryption_key_id is going to be ignored if encryption=default. So, basically we do not fix the root cause of what was reported in MDEV-17320, and instead of preventing that scenario by reporting an error, we will report a warning to make the user aware that the key will be ignored.
I documented the issues pointed out by marko here:
And created MDEV-19086 to track the fix.
http://lists.askmonty.org/pipermail/commits/2019-February/013456.html