On 5/5/06, Bryan Pendleton (JIRA) <derby-dev@db.apache.org> wrote:
>
> Hi Andrew. I'm comfortable with the use of Class.getResource() for this. That was actually the first solution that we tried for DERBY-668, and I agree that it appears to work well.

Wow. I had somehow already forgotten this. X-)

> I do think it's worth spending a bit of time re-visiting the discussion that was held for DERBY-668 and DERBY-930, though, because we seem to be going right back down the same path, and we don't want to just thrash back and forth. If nothing else, can you re-read those mail threads and comments and refresh your memory about how we got from getResource() to getProtectionDomain() in the first place?

The original concern was: "I thought a class loader was not allowed to
return the .class file as a resource for security reasons." The code
in DERBY-930 showed up around the same time and seemed like an
acceptable solution at the time. I think I've got a clearer
understanding of the issues involved having poked at the security
manager for a couple of months now.

Basically, yes, getResource() returns null if you don't have
permission to read the class, and that's not just fine, but the
behavior that we want to see. If we can't read the class, for whatever
reason, we can't load it or execute any code in it and so we don't
want to report it in the sysinfo output. As a diagnostic, if we were
expecting something to be in sysinfo's output, and it's not there,
that's the sign we're looking for that something is wrong. The
getProtectionDomain permission enabled us to discover the location of
a class that we still wouldn't be allowed to read in a really
restricted environment. The utility of this is limited, if not
misleading, and having to grant such a permission is not good. As
Kathey pointed out, the exception we print when we don't have the
permission will probably tempt users to add that permission to their
policy file, as they might think that the exception is a cause of
whatever problem they're having, and that's probably not a good thing.

So:

> I think that the current statement of things is something like:
>  - getProtectionDomain is a useful call, but it requires too many permissions under a SecurityManager, so for the purposes of SysInfo, which merely wants to report on the actual location from which an already-loaded class was loaded, we feel that getResource is a superior technique.

That pretty much sums it up. Either you have permission to read a
class, in which case we can report its location with getResource(), or
you don't, and we print nothing. The diagnostic value lies in whether
the sysinfo output matches up with the user's expectations of the
access they think they have to the Derby classes in their environment.

If you agree, I think we should each commit our patches for 1229 and
1273. Then I'll write up a comparison of sysinfo behavior in 10.1 with
the current behavior (including these patches) and make a case for
porting these fixes to 10.1 for the maintenance release.

andrew