Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <21804162.1192539452983.JavaMail.jira@brutus>
Date: Tue, 16 Oct 2007 05:57:32 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-857) LDAP user authentication fails under
 a security manager
In-Reply-To: <1487639121.1138044190846.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

This is the offending code  in LDAPAuthenticationSchemeImpl.  It is only an issue for a sane build and only with the property derby.debug.true=AuthenticationTrace set, which is probably why it hasn't come up on the user list.

Interestingly, nothing shows up in this file, for successful or unsuccessful connections and the com.sun.naming.ldap.trace.ber, I think is not portable.  Lastly the name  of the file CloudLDAP.out is not ideal.   I see three options
1) Put a priv block around this code. Change the filename and make sure the bug  doesn't reproduce.
2) Remove the code altogether since it is not portable/working.
3) Find some portable way to invoke LDAP tracing. Suggestions welcome.

if (SanityManager.DEBUG)
		{
			if (SanityManager.DEBUG_ON(
						AuthenticationServiceBase.AuthenticationTrace)) {
				try {
					initDirContextEnv.put("com.sun.naming.ldap.trace.ber",
								new java.io.FileOutputStream("CloudLDAP.out"));
				} catch (java.io.IOException ie) {}
			}
		}


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