[ http://issues.apache.org/jira/browse/DERBY-1273?page=all ]
Andrew McIntyre updated DERBY-1273:
-----------------------------------
Attachment: derby-1273-v2.diff
Attaching a second version of this patch. This patch attempts to get around the
need for the getProtectionDomain permission in all cases by attempting to
determine the location of the class via getResource(). If we have permission to
read the class, then we should be able to get its location via getResource().
If we don't, then formatURL throws a NullPointerException which is caught
higher up the stack and either reported as inaccessible (in the output of -cp)
or not reported at all (in the no-argument case). I contemplated catching this
null case, but if I did so in a security manager enabled environment then it
appeared as if the db2jcc libraries were located when executing with -cp, but
their location was not reported. I don't think this is the right thing to do in
this case. It seems like reporting that the class was not found was the right
thing to do.
Also, with this patch I now think that the headers for the -cp case are now
slightly inaccurate. "(NOT FOUND|FOUND) IN CLASSPATH" is slightly misleading,
since what we're really searching is the classloader context where sysinfo is
executing.
> Sysinfo should print a better message when it gets Security Exceptions
> accessing classpath info when run under security manager
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1273
> URL: http://issues.apache.org/jira/browse/DERBY-1273
> Project: Derby
> Type: Improvement
> Components: Tools
> Versions: 10.2.0.0
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: DERBY-1273.diff, derby-1273-v2.diff
>
> If sysinfo does not have getProtectionDomain privileges it cannot get some
> information during classpath handling.
> When this occurs it prints Java Security Exceptions in the output e.g.
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [C:\bryan\src\derby\main\trunk\jars\sane\derby.jar] 10.2.0.0 alpha - (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbytools.jar] 10.2.0.0 alpha -
> (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbynet.jar] 10.2.0.0 alpha -
> (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbyclient.jar] 10.2.0.0 alpha -
> (398049M)
> [Unable to access Protection Domain or Code Source for class class
> com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission
> getProtectionDomain)] 2.4 - (17)
> [C:\bryan\src\derby\main\trunk\jars\sane\db2jcc_license_c.jar] 2.4 - (17)
> [Java Security Exception: access denied (java.io.FilePermission
> c:\bryan\src\derby\main\trunk\tools\java\jakarta-oro-2.0.8.jar read)]
> [Java Security Exception: access denied (java.io.FilePermission
> c:\bryan\src\derby\main\trunk\tools\java\junit.jar read)]
> See DERBY-1229 notes.html for a complete explanation of the output.
> I am actually not sure what information is actually missing from sysinfo in
> this case but I think it would be better if sysinfo just printed the
> classpath and then printed a generic warning with the information that it
> was not able to report rather than printing the Security exceptions
> explicitly.
> This would be especially helpful for NetworkServerControl sysinfo because
> users are always encouraged to run network server in security manager.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
