[jira] [Comment Edited] (DERBY-6620) Network client DataSources silently swallow SecurityExceptions when trying to read the tracing properties

["Dag H. Wanvik (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103031#comment-14103031 ] 

Dag H. Wanvik edited comment on DERBY-6620 at 8/19/14 11:30 PM:
----------------------------------------------------------------

This is client side code. If it runs under a security manager, the reading of system properties *derby.client.traceDirectory* and *derby.client.traceLevel* can fail unless permissions are given in the policy file in use. Now, under normal operation, one wouldn't be using these properties; they are mainly available for debugging the protocol. So, does it really constitute a security issue if these properties can't be read?  It *could* trip up an admin trying to enable protocol tracing, and finding the trace file has ended up somewhere it shouldn't. 

So, would it be worth it to write a warning message on the console (where else?) in this case? It could be seen
as an annoyance if the user isn't trying to use tracing at all.... I am not quite convinced its the right thing to do. I would have liked the warning to appear only if tracing is attempted, but it appears the properties are always read, cf. BasicClientDataSource40#updateDataSourceValues, which is called from #getConnection unconditionally.


was (Author: dagw):
This is client side code. If it runs under a security manager, the reading of system properties *derby.client.traceDirectory* and *derby.client.traceLevel* can fail unless permissions are given in the policy file in use. Now, under normal operation, one wouldn't be using these properties; they are mainly available for debugging the protocol. So, does it really constitute a security issue if these properties can't be read?  It *could* trip up an admin trying to enable protocol tracing, and finding the trace file has ended up somewhere it shouldn't. 

So, would it be worth it to write a warning message on the console (where else?) in this case? It could be seen
as an annoyance if the user isn't trying to use tracing at all.... I am not quite convinced its the right thing to do. I would have liked the warning to appear only if tracing is attempted, but it the properties are always read, cf. BasicClientDataSource40#updateDataSourceValues, which is called from #getConnection unconditionally.

> Network client DataSources silently swallow SecurityExceptions when trying to read the tracing properties
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6620
>                 URL: https://issues.apache.org/jira/browse/DERBY-6620
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.11.1.1
>            Reporter: Rick Hillegas
>            Assignee: Dag H. Wanvik
>
> The swallowing occurs here:
> {noformat}
> org.apache.derby.jdbc.ClientBaseDataSourceRoot run Catch java.lang.SecurityException 1 line 457
> {noformat}
> Maybe a warning could be raised to alert the user to the problem and encourage them to correct their security policy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)