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
