db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anders Morken (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-1392) Corner case behaviour in RAFContainer#writePage() can cause invalid data to be written to data files
Date Fri, 09 Jun 2006 18:44:29 GMT
Corner case behaviour in RAFContainer#writePage() can cause invalid data to be written to data

         Key: DERBY-1392
         URL: http://issues.apache.org/jira/browse/DERBY-1392
     Project: Derby
        Type: Bug

  Components: Store  
 Environment: Platforms that throw an IOException when writing beyond the EOF, but permit
the write to proceed if the file is padded, then written.
    Reporter: Anders Morken
 Assigned to: Anders Morken 
    Priority: Minor
     Fix For:

java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java#writePage(...) will
attempt to retry a write if an IOException is thrown on the first attempt. However, the next

attempt does not add container header data to the first page, nor does it encrypt the data

if the database is encrypted.

I'd expect this bug to be case silent corruption of encrypted databases if the code path 
was actually exercised. The fact that this bug still lives and nobody has discovered it is
possibly an indication of how uncommon this code path is. Since the comment in the code
says nothing about exactly what platforms the workaround was intended for, I don't know if
these platforms are still supported for Derby. There's also a workaround for an EPOC Java
bug earlier in the code - EPOC only had a Java 1.1 VM, which is no longer supported.

I'll attach a patch for the issue, but I wonder if we might as well remove the "retry code
if it is never used?

(If you're paranoid, this could also be considered a security issue. If someone could
cause IO errors for Derby at will, they could make Derby write the database without 
encryption - but there are far easier ways to attack Derby if you've got that kind of 
access, so I'm discounting that. =)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message