db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db
Date Thu, 13 Jul 2006 17:53:31 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1156?page=all ]

Mike Matrigali updated DERBY-1156:
----------------------------------


Here are my comments on review of the reencrypt_4.diff, also I am running storeall but it
has not finished yet.:

minor typo's:
XactFactory.java line 835 - trasaction  --> transactions
TransactionTable.java: add comment that hasPreparedXact(boolean recovered) is
    also MT unsafe.

Is there a test for readonly db?

It is a little wierd to throw an exception from the ReadOnly impl of
checkVersion(), from the name of the routine.  I understand what the
comment is saying.  It seems unexpected for this routine to not return
ok for a "current" db.


stuff for now or later:
o may be interesting to add following to your tests on XA
    o have a global xact in the log that is aborted during recovery (ie.
      not yet prepared).
    o have a global xact in the log that is prepared and committed.

  I don't think there are code issues with these paths, mostly just easy
  cases to add and will verify future code doesn't break it.

o add test for readonly db and reencrypt.
o add test for upgrade fail.  Is there an existing framework for soft
  upgrade testing in 10.2?

> allow the encrypting of an existing unencrypted db and allow the re-encrypting of an
existing encrypted db
> ----------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1156
>          URL: http://issues.apache.org/jira/browse/DERBY-1156
>      Project: Derby
>         Type: Improvement

>   Components: Store
>     Versions: 10.1.2.3
>     Reporter: Mike Matrigali
>     Assignee: Suresh Thalamati
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: encryptspec.html, reencrypt_1.diff, reencrypt_2.diff, reencrypt_3.diff,
reencrypt_4.diff
>
> encrypted database to be re-encrypted with a new password.
> Here are some ideas for an initial implementation.
> The easiest way to do this is to make sure we have exclusive access to the
> data and that no log is required in the new copy of the db.  I want to avoid
> the log as it also is encrypted.  Here is my VERY high level plan:
> 1) Force exclusive access by putting all the work in the low level store,
>    offline boot method.  We will do redo recovery as usual, but at the end
>    there will be an entry point to do the copy/encrypt operation.
> copy/encrypt process:
> 0) The request to encrypt/re-encrypt the db will be handled with a new set
>    of url flags passed into store at boot time.  The new flags will provide
>    the same inputs as the current encrypt flags.  So at high level the
>    request will be "connect db old_encrypt_url_flags; new_encrypt_url_flags".
>    TODO - provide exact new flag syntax.
> 1) Open a transaction do all logged work to do the encryption.  All logging
>    will be done with existing encryption.
> 2) Copy and encrypt every db file in the database.  The target files will
>    be in the data directory.  There will be a new suffix to track the new
>    files, similar to the current process used for handling drop table in
>    a transaction consistent manner without logging the entire table to the log.
>    Entire encrypted destination file is guaranteed synced to disk before
>    transaction commits.  I don't think this part needs to be logged.
>    Files will be read from the cache using existing mechanism and written
>    directly into new encrypted files (new encrypted data does not end up in
>    the cache).
> 3) Switch encrypted files for old files.  Do this under a new log operation
>    so the process can be correctly rolled back if the encrypt db operation
>    transaction fails.  Rollback will do file at a time switches, no reading
>    of encrypted data is necessary.
> 4) log a "change encryption of db" log record, but do not update
>    system.properties with the change.
> 5) commit transaction.
> 6) update system.properties and sync changes.
> 7) TODO - need someway to handle crash between steps 5 and 6.
> 6) checkpoint all data, at this point guaranteed that there is no outstanding
>    transaction, so after checkpoint is done there is no need for the log.
> ISSUES:
> o there probably should be something that catches a request to encrypt to
>   whatever db was already encrypted with.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message