db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager
Date Wed, 17 Oct 2007 17:20:50 GMT

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

Kathey Marsden commented on DERBY-857:
--------------------------------------

Running with  -Djava.security.debug="access,failure,jar,domain" I get this more interesting
trace, but still no clue as to who needs the socket permissions.   I am not sure that there
is a fix for this.  I think maybe we have to document the workaround to  put 

grant {
  permission java.net.SocketPermission "<machine>", "connect,resolve";
};

in the policy file for LDAP. Anyone have thoughts on this?


access: access denied (java.net.SocketPermission <machine> resolve)

java.lang.Exception: Stack trace

	at java.lang.Thread.dumpStack(Thread.java:1206)

	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:313)

	at java.security.AccessController.checkPermission(AccessController.java:546)

	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)

	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1031)

	at java.net.InetAddress.getAllByName0(InetAddress.java:1128)

	at java.net.InetAddress.getAllByName0(InetAddress.java:1109)

	at java.net.InetAddress.getAllByName(InetAddress.java:1072)

	at java.net.InetAddress.getByName(InetAddress.java:969)

	at java.net.InetSocketAddress.<init>(InetSocketAddress.java:124)

	at java.net.Socket.<init>(Socket.java:179)

	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:349)

	at com.sun.jndi.ldap.Connection.<init>(Connection.java:184)

	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:118)

	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1580)

	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2616)

	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:287)

	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)

	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)

	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)

	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)

	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)

	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)

	at javax.naming.InitialContext.init(InitialContext.java:223)

	at javax.naming.InitialContext.<init>(InitialContext.java:197)

	at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)

	at org.apache.derby.impl.jdbc.authentication.LDAPAuthenticationSchemeImpl.getDNFromUID(LDAPAuthenticationSchemeImpl.java:442)

	at org.apache.derby.impl.jdbc.authentication.LDAPAuthenticationSchemeImpl.authenticateUser(LDAPAuthenticationSchemeImpl.java:160)

	at org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.authenticate(AuthenticationServiceBase.java:222)

	at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(EmbedConnection.java:583)

	at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:301)

	at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)

	at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:54)

	at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68)

	at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:211)

	at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)

	at java.sql.DriverManager.getConnection(DriverManager.java:582)

	at java.sql.DriverManager.getConnection(DriverManager.java:154)

	at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:1206)

	at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:1056)

	at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:884)

	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:328)

	at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)

	at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)

	at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)

	at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)

	at org.apache.derby.tools.ij.main(ij.java:59)



> 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.


Mime
View raw message