[
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535265
]
Kathey Marsden commented on DERBY-857:
--------------------------------------
Bryan said:
>I'm not sure how proposal (1) differs from proposal (3). Is there more
>to the LDAP tracing than just setting this value? Is it correct to say that
>(1) is the first step toward (3), but there may be more subsequent security
>problems to be resolved?
1 is the first step toward 3 I suppose, but the problem is that the tracing
does not seem to be working. Just an empty file gets created. I don't think it
is security problems but something else, I think I will do 1 and then open up
another task to investigate LDAP tracing with
derby.debug.true=AuthenticationTrace set. Does that sound ok?
> LDAP user authentication fails under a security manager
> -------------------------------------------------------
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
> Reporter: Daniel John Debrunner
> Assignee: Kathey Marsden
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException:
> > noSuchMachine:389 [Root exception is java.security.AccessControlException:
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
