[
https://issues.apache.org/jira/browse/DERBY-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030774#comment-13030774
]
Rick Hillegas commented on DERBY-5195:
--------------------------------------
Thanks for the comments, Mike. Some more discussion below...
MM> o personally I would rather not see these types of tools added as supported
to the DERBY project, but rather either as unsupported
SANE tools or as tools on top of derby in another project. I don't think the
production derby.jar should be weighed down with debugging code/tools.
If we decide to start "supporting" more
tools i think they should be checked into a different part of the codeline
and a different jar file. I do think it would be nice if there
was a place to check in unsupported tools on top of DERBY, and we have
discussed it in the past but nothing came of it. A number
of other things come to mind like user definined functions and datatypes. I
think there have been some useful VTI's that would
also fit into this.
It might make sense to distinguish between supported and unsupported tools. I
have attached a number of tools to JIRA issues. Technically I don't consider
myself responsible for fixing them when they don't work as advertised.
Practically speaking, I have been pretty responsive about fixing these tools
when complaints come in. It would be pretty funny if the distinction between
unsupported and supported turned out to be this: for an unsupported tool, a
Derby developer gives you a fix right away, whereas for a supported tool, you
won't get a fix until the next Derby release.
Another way to distinguish tools would be by who the target users are. The
programs in derbytools.jar seem to be aimed at the developers who write
Derby-powered apps, the dbas who administer those apps in production, and the
tech support engineers who field bugs logged against those apps. In contrast, I
suspect that ControlFileReader, LogFileReader, and DataFileReader will be used
mostly by derby-dev developers, that is, us. It's possible that these tools
might be used by tech support engineers who support specific Derby-powered
apps--but I think that is highly unlikely. I don't think those engineers want
to become experts in Derby's internal formats. To me, these new tools seem most
useful when the bug ends up in Derby's JIRA tracker.
Don't know if that helps push the conversation forward, but I thought it was
worth saying.
MM> o I scanned the DataReader file and it looked like it did not depend on
store at all, so would also benefit from not being in the
store file structure so that it keeps that independence.
LogFileReader imports org.apache.derby.iapi.store.raw.Loggable in order to get
its hands on some constants. It would be easy to break that dependency. Both
DataFileReader and LogFileReader depend on other machinery in the engine,
chiefly code under org.apache.derby.iapi.services.
MM> o I also worry if we productize these then they could be used in unintended
ways and may cause problems by their use. The intent
is to use single user on a copy of the database, but what happens if people
start running these against a running database either
by choice or accidently. A lot of the existing corruptions of DERBY have
come from users manipulating the log and datafiles by hand. I
would rather not encourage more to do so.
Don't know how these interactions would play out. The new tools merely read the
files in log and seg0. The tools never change the files though. Don't know if
merely reading these files would trip up another Derby engine.
MM> o These tools basically let anyone scan a table (sort of), how does that
fit in with SQL security?
Right. DataFileReader lets you print out a table if you have access to the
database directory and know both the table's conglomerate number and its row
signature. A moderately competent engineer could write this tool in less than a
week provided that they knew about the data formats described here:
http://db.apache.org/derby/papers/pageformats.html So, the tool costs maybe a
couple thousand dollars to write. Amortized over just a couple criminal
customers, the cost per crime could be even lower. Note also that you can view
a surprising amount of a Derby database by just cat'ing the files in seg0. I
would agree that the tools slightly increase the vulnerability of low value
data.
> Create tools for browsing the files in the database log directory.
> ------------------------------------------------------------------
>
> Key: DERBY-5195
> URL: https://issues.apache.org/jira/browse/DERBY-5195
> Project: Derby
> Issue Type: Task
> Affects Versions: 10.9.0.0
> Reporter: Rick Hillegas
> Attachments: ControlFileReader.java, ControlFileReader.java,
> LogFileReader.java, LogFileReader.java, LogFileReader.java
>
>
> It would be nice to have some tools to examine the contents of the log
> directory. The tools should be able to read the files in that directory
> without disturbing them.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
