db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Working with security policy
Date Mon, 23 Jan 2006 23:10:48 GMT
I think I need to write up something explaining what I am doing with 
classloaders that you all can look at and review.  But that's 
back-burnered right now until I can get the client code 
internationalized, that's a bigger itch for "me" right now :)

David

Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
> 
> 
> 
>>>>When I was doing the classloader work, I had to grant permission to
>>>>the Derby codebase to be able to do classloader-related work
>>>>(createClassloader, accessClassInPackage.sun.reflect, getClassloader,
>>>>getProtectionDomain).
> 
> 
> If there's a good justification for a permission then it's fine to make
> Derby dependent on it. From a high level view of what you are doing I
> would have concerns about Derby code needing
> accessClassInPackage.sun.reflect, getClassloader and
> getProtectionDomain. Esepecially the one with sun.reflect, isn't that
> granting internal access to a class of a specific VM implementation?
> 
> I look at the problem from the view of someone who is running Derby on
> behalf of a third-party application on their own machine. What minimal
> set of permissions do they have to grant to Derby? What's the
> explanation for those permissions? Can they feel comfortable running
> such an application with the permissions granted?
> 
> If we said Derby has to be granted permission to read all files, read
> and write all system properties, etc. then Derby would not be attractive
> in those situations.
> 
> 
>>>>How do I know whether granting a certain permission is shadowing a
>>>>"bug" versus the right thing to do?
> 
> 
> I don't think there's any shortcut here. One has to understand what
> resources Derby accesses and does/could that new permission have any
> effect on those existing accesses.
> 
> There were/are two ways that I see that granting a permission for reason
> X could hide a bug:
> 
>   1) The permission is granted to multiple jars when only one jar
> requires it. Now that the policy file for the tests split the grants
> into per-jar sections the chance of this should be low.
> 
>   2) The permission granted is broader than is actually required for X,
> and so other code can using it without anyone realising that such a
> dependency exists. E.g. granting read on all properties hides the fact
> that the engine might be incorrectly reading user.dir when it should be
> limited to derby.* properties.
> 
> Part of my DERBY-615 work is to deliver a write-up on the existing
> security permissions needed.
> 
> Dan.
> 
> 

Mime
View raw message