db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1273) Sysinfo should print a better message when it gets Security Exceptions accessing classpath info when run under security manager
Date Fri, 05 May 2006 07:37:18 GMT
     [ 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:
>     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] alpha - (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbytools.jar] alpha - (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbynet.jar] alpha - (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbyclient.jar] 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
> [Java Security Exception: access denied (java.io.FilePermission c:\bryan\src\derby\main\trunk\tools\java\junit.jar
> 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:
For more information on JIRA, see:

View raw message