Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <7603839.1149885571495.JavaMail.jira@brutus>
Date: Fri, 9 Jun 2006 20:39:31 +0000 (GMT+00:00)
From: "Anders Morken (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1392) Corner case behaviour in
 RAFContainer#writePage() can cause invalid data to be written to data files
In-Reply-To: <22741629.1149878669882.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DERBY-1392?page=all ]

Anders Morken updated DERBY-1392:
---------------------------------

    Derby Info: [Patch Available]

> Corner case behaviour in RAFContainer#writePage() can cause invalid data to be written to data files
> ----------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1392
>          URL: http://issues.apache.org/jira/browse/DERBY-1392
>      Project: Derby
>         Type: Bug

>   Components: Store
>     Versions: 10.1.2.0
>  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
>     Assignee: Anders Morken
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: DERBY-1392-1.patch
>
> 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 path"
> 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira