Bug #95183 | redo logs may silently be ignored when encrypted table cannot be decrypted. | ||
---|---|---|---|
Submitted: | 29 Apr 2019 11:02 | Modified: | 22 Jul 2019 18:30 |
Reporter: | Robert Golebiowski | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Security: Encryption | Severity: | S3 (Non-critical) |
Version: | 8.0.15 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[29 Apr 2019 11:02]
Robert Golebiowski
[7 May 2019 14:38]
MySQL Verification Team
Hello Robert, Thank you for your bug report. This bug report makes lots of sense to me. However, I need a couple of additional info in order to be able to repeat it and understand it. First of all, can you provide just CREATE TABLE commands for those encrypted tables. Second, I see that release server will start successfully. What happens with a debug server, exactly ??? Third, I see two snippets of code. How do you think that the code in release server should be changed, or whether do you think that the particular ut_ad() should be converted to ut_a() ??? Fourth, are there any consequences with those tables or redo log if the restart is successful as in the release server ??? Simply, I would like to hear the reasoning behind your thinking ...... Thanks in advance.
[13 May 2019 13:03]
MySQL Verification Team
Hi Mr. Golebiowski, We are still waiting on your feedback. Can you, please, provide it, together with a full test case on how to repeat the behaviour ??? We are asking you this, because we are very much interested in fixing this behaviour !!!!!! Thanks in advance !!!!!
[17 May 2019 10:49]
Robert Golebiowski
Hi Sinisa, Why so serious ? ;) Sorry, I have been busy lately. I have prepared the testcase. Please find it attached. Note, that for the debug build this test will pass and for the release it will hung on: --error 1 --exec $MYSQLD_CMD --log-error=$error_log This is because the test will not abort with error as it should have, but initialize successfully.
[17 May 2019 10:50]
Robert Golebiowski
the testcase
Attachment: bug95183.test (application/octet-stream, text), 2.08 KiB.
[17 May 2019 10:51]
Robert Golebiowski
master file for the testcase
Attachment: bug95183-master.opt (application/octet-stream, text), 134 bytes.
[17 May 2019 10:59]
Robert Golebiowski
To answer your question - the redo log for encrypted tables will silently be lost for release server. This breaks ACID.
[17 May 2019 12:27]
MySQL Verification Team
Hi, Thank you for your test case. We shall run it and will let you know of the results.
[17 May 2019 14:26]
MySQL Verification Team
Hi, You have specified in your .opt file the following option pertaining the key ring file data: $MYSQLTEST_VARDIR/std_data/keys2.txt I have on my machine several text files with encryption keys, but I do not know if those will work with your test case. Also, if any of the key files in current MTR datadir can be used instead, just let us know. Otherwise, please, upload your keys2.txt, just to be sure. You can use "Files" tab and upload it as a hidden file. Thanks in advance.
[20 May 2019 10:49]
Robert Golebiowski
Hi Sinisa, Actually you can just replace it with $MYSQLTEST_VARDIR/tmp/keys.txt. It will create keyring with encryption keys needed. it should also work as it is. If the file does not exist it will create it and put the encryption keys in it. Hopes it helps Robert
[21 May 2019 13:55]
MySQL Verification Team
HI, I have managed to repeat a test case from your bug report. Verified as reported. Thanks a lot.
[22 Jul 2019 18:30]
Daniel Price
Posted by developer: Fixed as of the upcoming 8.0.18 release, and here's the changelog entry: During recovery, missing table errors that occur when applying redo logs to encrypted tables could be ignored, permitting startup to proceed. Startup should be halted in this case.
[23 Jul 2019 13:42]
MySQL Verification Team
Thank you, Daniel !