You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Suresh Thalamati <su...@gmail.com> on 2005/04/15 20:31:42 UTC
corrupt disk io storage factory for testing.
Hi,
I am looking at creating a new corruptible storage factory by
extending the engine's disk storage factory.
Purpose of this is to do explicitly corrupt the IO and do some
recovery testing. Thought ideal place
for the corruptible storage factory is to be in the test code
utilities not in the code line. But I ran into a simple obstacle ,
constructors in the org.apache.derby.impl.io.DirFile etc are package
protected. So I am unable to extend the disk storage
factory classes successfully .
I was wondering if there was any reason for not making constructors
public or it was just that there was not requirement to do ?
If no one has any objections I would like to modify them to be
accessible outside org.apache.derby.impl.io.* package ?
Thanks
-suresht
Re: corrupt disk io storage factory for testing.
Posted by David Van Couvering <Da...@Sun.COM>.
Sorry, Suresh, I didn't catch that these were constructors. I agree, no
risk there.
What I was worried about was making public actual methods or fields on
internal storage classes. If it is possible for a Java stored procedure
(or any other code running in the same VM) to access the underlying data
without having to be authenticated as a user and without having to go
through appropriate authorization, then it would seem this would be a
security problem. I don't know the Derby storage architecture very
well yet. I don't know if this is possible or not, but anyway, that was
my concern.
Thanks,
David
Suresh Thalamati wrote:
> Hi David,
>
> I Don't quite understand how making few internal class constructors
> puiblic poses security risk, guess I need to
> do some more reading in this area. In the existing code anyone can
> instantiate the disk storage factory and use it:
> package org.apache.derby.impl.io:
> public class DirStorageFactory extends BaseStorageFactory implements
> WritableStorageFactory
>
> Does the above class definition poses any security risks ?
> My guess is it does not because there are no privelaged blocks inside
> this factory implementation. Derby Raw Store
> accesses the DirStoreageFactory class methods under priveleged blocks
> when needed.
> Thanks
> -suresh
>
> David Van Couvering wrote:
>
>> Maybe I'm missing something, but isn't making internal classes public
>> an inherent security risk? Unless these APIs do security checks
>> (authorization checks of an authenticated user), then they shouldn't
>> be public, IMHO. This is especially risky given that Derby supports
>> server-side Java...
>>
>> Thanks,
>>
>> David
>>
>> Suresh Thalamati wrote:
>>
>>>
>>> Hi,
>>>
>>> I am looking at creating a new corruptible storage factory by
>>> extending the engine's disk storage factory.
>>> Purpose of this is to do explicitly corrupt the IO and do some
>>> recovery testing. Thought ideal place
>>> for the corruptible storage factory is to be in the test code
>>> utilities not in the code line. But I ran into a simple obstacle ,
>>> constructors in the org.apache.derby.impl.io.DirFile etc are
>>> package protected. So I am unable to extend the disk storage
>>> factory classes successfully .
>>>
>>> I was wondering if there was any reason for not making
>>> constructors public or it was just that there was not requirement to
>>> do ?
>>> If no one has any objections I would like to modify them to be
>>> accessible outside org.apache.derby.impl.io.* package ?
>>>
>>> Thanks
>>> -suresht
>>>
>>>
>>
>
>
Re: corrupt disk io storage factory for testing.
Posted by Suresh Thalamati <su...@gmail.com>.
Hi David,
I Don't quite understand how making few internal class constructors
puiblic poses security risk, guess I need to
do some more reading in this area. In the existing code anyone can
instantiate the disk storage factory and use it:
package org.apache.derby.impl.io:
public class DirStorageFactory extends BaseStorageFactory implements
WritableStorageFactory
Does the above class definition poses any security risks ?
My guess is it does not because there are no privelaged blocks inside
this factory implementation. Derby Raw Store
accesses the DirStoreageFactory class methods under priveleged blocks
when needed.
Thanks
-suresh
David Van Couvering wrote:
> Maybe I'm missing something, but isn't making internal classes public
> an inherent security risk? Unless these APIs do security checks
> (authorization checks of an authenticated user), then they shouldn't
> be public, IMHO. This is especially risky given that Derby supports
> server-side Java...
>
> Thanks,
>
> David
>
> Suresh Thalamati wrote:
>
>>
>> Hi,
>>
>> I am looking at creating a new corruptible storage factory by
>> extending the engine's disk storage factory.
>> Purpose of this is to do explicitly corrupt the IO and do some
>> recovery testing. Thought ideal place
>> for the corruptible storage factory is to be in the test code
>> utilities not in the code line. But I ran into a simple obstacle ,
>> constructors in the org.apache.derby.impl.io.DirFile etc are
>> package protected. So I am unable to extend the disk storage
>> factory classes successfully .
>>
>> I was wondering if there was any reason for not making
>> constructors public or it was just that there was not requirement to
>> do ?
>> If no one has any objections I would like to modify them to be
>> accessible outside org.apache.derby.impl.io.* package ?
>>
>> Thanks
>> -suresht
>>
>>
>
Re: corrupt disk io storage factory for testing.
Posted by David Van Couvering <Da...@Sun.COM>.
Maybe I'm missing something, but isn't making internal classes public an
inherent security risk? Unless these APIs do security checks
(authorization checks of an authenticated user), then they shouldn't be
public, IMHO. This is especially risky given that Derby supports
server-side Java...
Thanks,
David
Suresh Thalamati wrote:
>
> Hi,
>
> I am looking at creating a new corruptible storage factory by
> extending the engine's disk storage factory.
> Purpose of this is to do explicitly corrupt the IO and do some
> recovery testing. Thought ideal place
> for the corruptible storage factory is to be in the test code utilities
> not in the code line. But I ran into a simple obstacle ,
> constructors in the org.apache.derby.impl.io.DirFile etc are package
> protected. So I am unable to extend the disk storage
> factory classes successfully .
>
> I was wondering if there was any reason for not making constructors
> public or it was just that there was not requirement to do ?
> If no one has any objections I would like to modify them to be
> accessible outside org.apache.derby.impl.io.* package ?
>
> Thanks
> -suresht
>
>
Re: corrupt disk io storage factory for testing.
Posted by Suresh Thalamati <su...@gmail.com>.
Thanks for the suggestion. I agree Proxy is better way to do this. I
am getting an assertion failure when I try to
create database with a proxy storage factory. Am I missing some
property or is it a problem ?
java
-Dderby.subSubProtocol.csf=org.apache.derbyTesting.functionTests.util.corruptio.CorruptDiskStorageFactory
org.apache.derby.tools.ij
ij> connect 'jdbc:derby:csf:wombat1;create=true';
ERROR XJ001: Java exception: 'ASSERT FAILED mismatched canonical names
csf:C:\suresht\databases\wombat1 != C:\suresht\databases\wombat1:
org.apache.derby.iapi.s
ervices.sanity.AssertFailure'.
Stack :
============= begin nested exception, level (1) ===========
org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED
mismatched canonical names csf:C:\suresht\databases\wombat1 !=
C:\suresht\databases\wombat1
at
org.apache.derby.iapi.services.sanity.SanityManager.ASSERT(SanityManager.java:121)
at
org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1773)
at
org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java:1018)
at
org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java:578)
at
org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(EmbedConnection.java:1509)
at
org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:220)
at
org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:72)
at
org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:73)
at
org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:183)
at java.sql.DriverManager.getConnection(DriverManager.java:512)
at java.sql.DriverManager.getConnection(DriverManager.java:140)
at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:838)
at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:700)
at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:528)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:289)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:209)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:175)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
at org.apache.derby.tools.ij.main(ij.java:60)
============= end nested exception, level (1) ===========
Cleanup action completed
Thanks
-suresht
Daniel John Debrunner wrote:
>Suresh Thalamati wrote:
>
>
>>Hi,
>>
>> I am looking at creating a new corruptible storage factory by
>>extending the engine's disk storage factory.
>> Purpose of this is to do explicitly corrupt the IO and do some
>>recovery testing. Thought ideal place
>> for the corruptible storage factory is to be in the test code utilities
>>not in the code line. But I ran into a simple obstacle ,
>> constructors in the org.apache.derby.impl.io.DirFile etc are package
>>protected. So I am unable to extend the disk storage
>> factory classes successfully .
>>
>>
>
>Why not make a proxy storage factory that delegates to another storage
>factory, but performs any corruptions you require? Then the corruption
>testing would be independent of the underlying storage and not tied to
>the current disk implementation.
>
>Dan.
>
>
>
>
>
Re: corrupt disk io storage factory for testing.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Suresh Thalamati wrote:
>
> Hi,
>
> I am looking at creating a new corruptible storage factory by
> extending the engine's disk storage factory.
> Purpose of this is to do explicitly corrupt the IO and do some
> recovery testing. Thought ideal place
> for the corruptible storage factory is to be in the test code utilities
> not in the code line. But I ran into a simple obstacle ,
> constructors in the org.apache.derby.impl.io.DirFile etc are package
> protected. So I am unable to extend the disk storage
> factory classes successfully .
Why not make a proxy storage factory that delegates to another storage
factory, but performs any corruptions you require? Then the corruption
testing would be independent of the underlying storage and not tied to
the current disk implementation.
Dan.