db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: corrupt disk io storage factory for testing.
Date Fri, 15 Apr 2005 23:26:27 GMT
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
>>>
>>>
>>
> 
> 

Mime
View raw message