[
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535656
]
Kathey Marsden commented on DERBY-857:
--------------------------------------
Dan said
>How about just removing the code, since it's just sanity and isn't really a
>benefit?
>Or just catching the security exception and continuing?
>I think the code was probably put there during the original development of
>LDAP authentication, I doubt it's >needed now.
>
The original security exception was for the tracing and I was able to resolve
that by adding a privilege block around the code. (It could also be removed.)
That got me further but the problem now is in the heart of the LDAP processing,
in .LDAPAuthenticationSchemeImpl.authenticateUser where we call:
// it is happening right here
DirContext ctx = privInitialDirContext(env);
and get
ERROR 08004: Connection refused : javax.naming.CommunicationException:
socket.usca.ibm.com:389 [Root exception is
java.security.AccessControlException: access denied (java.net.SocketPermission
socket.usca.ibm.com resolve)]
I will go ahead and post the patch for the change to get us past the tracing
file problem so that you can see the same failure I am seeing. You can see it
is a javax.naming.CommunicationException that is thrown not a Security
Excepition, so wrapping this call in a privilege block is not helpful.
Kathey
> 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.
