db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: shutdown fails when basic security policy is active and authentication is ldap based
Date Thu, 05 Jun 2008 18:34:11 GMT
Hi Andreas,

I agree that this issue ought to be documented. For what it's worth, I'm 
close to publishing a white paper on 10.4 security. That paper mentions 
this issue. I would like to see Derby's security documentation 
overhauled. This is one among many important issues which are either 
missing from Derby's documentation or hard to find because the security 
topics are scattered about the manuals.

Regards,
-Rick

Andreas Kyrmegalos wrote:
> Hello,
>  just wanted to report an issue I have encountered. I searched JIRA 
> but I didn't come accross anything relevant. What I did do is read 
> issue 2196 thoroughly. Not one of the linked issues is related to what 
> I have encountered.
>
>
> I 'm using derby 10.4.1.3, specifically the binary release (648379), 
> on a windows XP machine.
>
> The basic security manager is throwing:
>
> 08004:Connection refused : javax.naming.CommunicationException: 
> 192.168.x.x:10389 [Root exception is 
> java.security.AccessControlException: access denied 
> (java.net.SocketPermission  192.168.x.x:10389 connect,resolve)]
>
> if ldap is the authentication provider, during system shutdown (and 
> most likely whenever derby attempts to access the ldap server, haven't 
> gotten around to that yet). Derby is started as a network server from 
> the command line (NetworkServerControl start and NetworkServerControl 
> shutdown are invoked).
>
> A security socket permission has to be enabled for derby.jar that will 
> allow opening a connection to the ldap server.
> Since the default security manager is activated before any access to 
> the derby.properties file, no fields related to ldap can be passed to 
> the server.policy file. Allowing derby to connect to any host is 
> obviously a security risk so such an option should not be considered.
>
> Therefore, I believe it is extremely important that it gets documented 
> in the Developer's Guide. A suggestion should appear in section /Derby 
> and Security/Configuring security in a client/server environment/. A 
> more detailed description of the issue must be documented in section 
> /Derby and Security/External directory service./ Something along the 
> lines of,
>
> ...
> ...in order to use derby with an ldap server in a production 
> environment a custom security policy file has to be deployed that will 
> allow derby, among other things,  to access the ldap server.
>
> Example for a security.policy file. Derby in installed in the 
> c:\derbyDB directory and the ldap server is located at host 
> ldap.example.com port 10389.
>
> grant codeBase "file:/c:/derbydb/lib/derby.jar"
> {
> // This permission is neccesary if ldap is selected as an 
> authentication provider
>
>  permission java.net.SocketPermission "ldap.example.com:10389", 
> "connect";
>
> ...
>
> Andreas


Mime
View raw message