db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5792) Make it possible to turn off encryption on an already encrypted database.
Date Wed, 03 Oct 2012 17:32:08 GMT

    [ 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

Mime
View raw message