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.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
