[
https://issues.apache.org/jira/browse/DERBY-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468688#comment-13468688
]
Kristian Waagan commented on DERBY-5792:
----------------------------------------
Thanks for the review, Knut Anders.
Answers/comments below.
> What does this mean exactly? Can any user decrypt the database with the
> current state of the patch?
Any user that knows the boot password / encryption key can decrypt the database
with patch 3a.
Nothing will happen if the database has already been booted. Assuming the DBO
boots the database by supplying the boot credentials, JOE_USER can't decrypt
the database. "decryptDatabase=true" will be ignored when JOE_USER connects to
the booted database. This hasn't changed with this patch, encryption attributes
are handled the same way.
I have a patch adding the restriction that only the DBO can decrypt a database,
given that authentication and authorization is enabled. The code will go in
toghether with changes to the DboPowersTest.
> Is it really the case that it's possible to end up encrypting the page even
> if the data factory says it shouldn't be encrypted?
I think this is a chicken and egg issue. The state of the data factory, and log
factory, isn't flipped until the operation has been carried out.
There are now three different data paths, where data goes in and out of the
cache "concurrently":
encrypt existing: [disk] -> plain -> [cache] -> encrypt -> [disk]
re-encrypt db : [disk] -> decrypt -> [cache] -> encrypt -> [disk]
decrypt db : [disk] -> decrypt -> [cache] -> plain -> [disk]
I'd have to check how the databaseEncrypted flags affect the decryption process
as data enters the page cache before trying to simplify/change this.
In any case, the existing check for encryptWithNewEngine is there to deal with
the case of encrypting an existing plaintext database.
I also see that setting the encryption buffer to null is used as an
optimization in RAFContainer4, and in that case DataFactory.encryptedDatabase()
is always false. This is normal operation though, not a case where the whole
database will transition from plaintext to ciphertext or vice versa.
> The new DATABASE_DECRYPTION_DENIED message might be problematic to localize
> because it takes an English string as an argument.
Yes, I'm aware of this. We need to nail down the messages.
I like the point about reusing the same SQL state. The important issue here is
that the decryption request was denied, not why. I say that, because it is
unlikely that this failure condition can be dealt with automatically by code. A
DBA would likely have to read the message - which does tell you why the request
was denied - and take corrective actions anyway. Also, encrypting and
decrypting a database is hopefully not something you do frequently on a given
database.
Encryption has different states for each failure condition:
<text>Cannot encrypt the database when there is a global transaction in the
prepared state.</text>
<text>Cannot re-encrypt the database with a new boot password or an external
encryption key when there is a global transaction in the prepared state.</text>
<text>Cannot configure a read-only database for encryption.</text>
<text>Cannot re-encrypt a read-only database with a new boot password or an
external encryption key .</text>
<text>Cannot configure a database for encryption, when database is in the log
archive mode.</text>
<text>Cannot re-encrypt a database with a new boot password or an external
encryption key, when database is in the log archive mode.</text>
<text>Encryption of an un-encrypted database failed: {0}</text>
<text>Encryption of an encrypted database with a new key or a new password
failed: {0}</text>
Guess I'll add another four messages to the heap:
<text>Cannot decrypt the database when there is a global transaction in the
prepared state.</text>
<text>Cannot configure a read-only database for decryption.</text>
<text>Cannot configure a database for decryption, when database is in the log
archive mode.</text>
<text>Decryption of an encrypted database failed: {0}</text>
The new messages follow the style of the existing messages. Are they good
enough, or should they be rewritten?
> Make it possible to turn off encryption on an already encrypted database.
> -------------------------------------------------------------------------
>
> Key: DERBY-5792
> URL: https://issues.apache.org/jira/browse/DERBY-5792
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Store
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
> Assignee: Kristian Waagan
> Attachments: derby-5792-1a-boilerplate_and_preparation.diff,
> derby-5792-1b-boilerplate_and_preparation.diff,
> derby-5792-2a-decryptdatabasetest.diff, derby-5792-3a-decryption_feature.diff
>
>
> Currently, you can encrypt an unencrypted database and you can change the
> encryption key on an already encrypted database. However, Derby does not
> expose a way to turn off (unencrypt) an already encrypted database.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
