[MDEV-17229] Encryption threads ignore innodb_default_encryption_key_id Created: 2018-09-18 Updated: 2023-04-27 |
|
| Status: | Stalled |
| Project: | MariaDB Server |
| Component/s: | Encryption, Storage Engine - InnoDB |
| Affects Version/s: | 10.1, 10.3.9, 10.2 |
| Fix Version/s: | 10.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Robert Golebiowski | Assignee: | Thirunarayanan Balathandayuthapani |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
When tablespace is to be encrypted by encryption threads (encryption unencrypted => encrypted) the tablespace will be always encrypted with key id 0. Encryption threads ignore the value of innodb_default_encryption_key_id. innodb_default_encryption_key_id should be used when encrypting unencrypted=>encrypted with encryption thread. |
| Comments |
| Comment by Jan Lindström (Inactive) [ 2018-11-07 ] |
|
https://github.com/MariaDB/server/commit/494dfb14f29faa066926f87545a173ad676e669b |
| Comment by Marko Mäkelä [ 2018-11-07 ] |
|
I believe that it is completely unacceptable for a SET SESSION statement to cause an assignment of a separate global variable that controls some background threads. Could the global variable be accessed by THDVAR(NULL, default_encryption_key_id)? SET GLOBAL also ought to require more privileges than SET [SESSION]. Before submitting a revised patch, please write clear user documentation or high-level specification of how all this is supposed to work. I cannot review code changes without having a solid specification first. |
| Comment by Jan Lindström (Inactive) [ 2018-11-12 ] |
|
https://github.com/MariaDB/server/commit/9c46adbb7e093029c56dddd5dbbef407db4e8160 |
| Comment by Marko Mäkelä [ 2018-11-12 ] |
|
This is better, I do not think it is OK to issue warnings for ignoring parameters that were not specified by the user. Please revise and resubmit for review. |
| Comment by Jan Lindström (Inactive) [ 2018-11-14 ] |
|
https://github.com/MariaDB/server/commit/2eba5d6eabdd3f82bcc9859bb9333e1909ec0852 |
| Comment by Marko Mäkelä [ 2019-01-10 ] |
|
Sorry for taking so long; I had not noticed the state change. |