Derby
  1. Derby
  2. DERBY-857

LDAP user authentication fails under a security manager

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
    • Fix Version/s: 10.3.2.1, 10.4.1.3
    • Component/s: Services
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      Patch Available
    • Bug behavior facts:
      Security

      Description

      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";

      1. derby-857_diff.txt
        3 kB
        Kathey Marsden

        Activity

        Daniel John Debrunner created issue -
        Rick Hillegas made changes -
        Field Original Value New Value
        Urgency Normal
        Hide
        Rick Hillegas added a comment -

        Moving to 10.2.2.0.

        Show
        Rick Hillegas added a comment - Moving to 10.2.2.0.
        Rick Hillegas made changes -
        Fix Version/s 10.2.1.0 [ 11187 ]
        Fix Version/s 10.2.2.0 [ 12312027 ]
        Hide
        Rick Hillegas added a comment -

        Move to 10.2.3.0.

        Show
        Rick Hillegas added a comment - Move to 10.2.3.0.
        Rick Hillegas made changes -
        Fix Version/s 10.2.3.0 [ 12312215 ]
        Fix Version/s 10.2.2.0 [ 12312027 ]
        Hide
        Andrew McIntyre added a comment -

        Unsetting Fix Version for unassigned issues.

        Show
        Andrew McIntyre added a comment - Unsetting Fix Version for unassigned issues.
        Andrew McIntyre made changes -
        Fix Version/s 10.2.3.0 [ 12312215 ]
        Kathey Marsden made changes -
        Assignee Kathey Marsden [ kmarsden ]
        Hide
        Kathey Marsden added a comment - - edited

        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. 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 working.
        3) Try to get LDAP tracing working. 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) {}
        }
        }

        Show
        Kathey Marsden added a comment - - edited 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. 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 working. 3) Try to get LDAP tracing working. 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) {} } }
        Hide
        Bryan Pendleton added a comment -

        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?

        Show
        Bryan Pendleton added a comment - 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?
        Hide
        Kathey Marsden added a comment -

        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?

        Show
        Kathey Marsden added a comment - 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?
        Hide
        Kathey Marsden added a comment -

        Well, putting the tracing in a priv block gets me further but there are still permission problems.
        2007-10-16 21:49:44.968 GMT Thread[main,5,main] Cleanup action starting

        java.sql.SQLException: 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)]

        at org.apache.derby.impl.jdbc.authentication.JNDIAuthenticationSchemeBase.getLoginSQLException(JNDIAuthenticationSchemeBase.java:122)

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

        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)

        Cleanup action completed

        The code that generates the exception is not a socket call directly but rather
        env.put(Context.SECURITY_PRINCIPAL, userDN);
        env.put(Context.SECURITY_CREDENTIALS, userPassword);

        // Connect & authenticate (bind) to the LDAP server now

        // it is happening right here
        DirContext ctx = new InitialDirContext(env);

        Wrapping this code in a priv block does no good because it is the root exception which is not exposed that is the problem.
        I'm not sure which jar to give the permission to.

        grant

        { permission java.net.SocketPermission "*", "connect,resolve"; }

        ;

        works, but is more liberal than we want I think.

        Show
        Kathey Marsden added a comment - Well, putting the tracing in a priv block gets me further but there are still permission problems. 2007-10-16 21:49:44.968 GMT Thread [main,5,main] Cleanup action starting java.sql.SQLException: 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)] at org.apache.derby.impl.jdbc.authentication.JNDIAuthenticationSchemeBase.getLoginSQLException(JNDIAuthenticationSchemeBase.java:122) at org.apache.derby.impl.jdbc.authentication.LDAPAuthenticationSchemeImpl.authenticateUser(LDAPAuthenticationSchemeImpl.java:196) 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) Cleanup action completed The code that generates the exception is not a socket call directly but rather env.put(Context.SECURITY_PRINCIPAL, userDN); env.put(Context.SECURITY_CREDENTIALS, userPassword); // Connect & authenticate (bind) to the LDAP server now // it is happening right here DirContext ctx = new InitialDirContext(env); Wrapping this code in a priv block does no good because it is the root exception which is not exposed that is the problem. I'm not sure which jar to give the permission to. grant { permission java.net.SocketPermission "*", "connect,resolve"; } ; works, but is more liberal than we want I think.
        Hide
        Kathey Marsden added a comment -

        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)

        Show
        Kathey Marsden added a comment - 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)
        Hide
        Daniel John Debrunner added a comment -

        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.

        Show
        Daniel John Debrunner added a comment - 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.
        Hide
        Kathey Marsden added a comment -

        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

        Show
        Kathey Marsden added a comment - 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
        Hide
        Kathey Marsden added a comment -

        This first patch adds a privilege block around creation of the tracing file. If creation of the tracing file fails, execution will continue. It does not cause the core problem of making a connection to the LDAP server if we don't include

        grant

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

        ;

        Show
        Kathey Marsden added a comment - This first patch adds a privilege block around creation of the tracing file. If creation of the tracing file fails, execution will continue. It does not cause the core problem of making a connection to the LDAP server if we don't include grant { permission java.net.SocketPermission "<machine>", "resolve,connect"; } ;
        Kathey Marsden made changes -
        Attachment derby-857_diff.txt [ 12367893 ]
        Kathey Marsden made changes -
        Derby Info [Patch Available]
        Hide
        Kathey Marsden added a comment -

        Investigating this further I find that I need to give the permission to the top level program, for example if I use ij to connect I need to give the SocketPermission to derbytools.jar. If I write a small program to connect. I need to give that program permission. e.g.

        grant codeBase "file:c:/kmarsden/repro/DERBY-857/-"

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

        ;

        Show
        Kathey Marsden added a comment - Investigating this further I find that I need to give the permission to the top level program, for example if I use ij to connect I need to give the SocketPermission to derbytools.jar. If I write a small program to connect. I need to give that program permission. e.g. grant codeBase "file:c:/kmarsden/repro/ DERBY-857 /-" { permission java.net.SocketPermission "<machine>", "resolve,connect"; } ;
        Hide
        Daniel John Debrunner added a comment -

        That's usually an indication that you are missing a priv block.
        The last stack trace above (dated 10/17 10:20) shows no priv block, thus I would expect a SecuityException,
        but the previous comment says that adding a priv block makes no difference. Do you have the stack trace when that it is the case?

        Show
        Daniel John Debrunner added a comment - That's usually an indication that you are missing a priv block. The last stack trace above (dated 10/17 10:20) shows no priv block, thus I would expect a SecuityException, but the previous comment says that adding a priv block makes no difference. Do you have the stack trace when that it is the case?
        Hide
        Kathey Marsden added a comment -

        Thanks Dan for your time in looking at this. There was indeed another call to InitialDirContext where I missed putting a privilege block. It all works fine now. I will prepare a patch with the full fix.

        Kathey

        Show
        Kathey Marsden added a comment - Thanks Dan for your time in looking at this. There was indeed another call to InitialDirContext where I missed putting a privilege block. It all works fine now. I will prepare a patch with the full fix. Kathey
        Hide
        Kathey Marsden added a comment -

        I accidentally checked in my changes for this issue revision 586052 a bit prematurely. I think the changes are what I want them to be, so I will leave review to post commit and change whatever's needed. I have been doing some manual testing with LDAP. We can't have a regression test without having an LDAP server setup.

        Show
        Kathey Marsden added a comment - I accidentally checked in my changes for this issue revision 586052 a bit prematurely. I think the changes are what I want them to be, so I will leave review to post commit and change whatever's needed. I have been doing some manual testing with LDAP. We can't have a regression test without having an LDAP server setup.
        Hide
        Daniel John Debrunner added a comment -

        Minor question on the code change (revision 586052).

        Is there any reason for creating two extra methods, rather than performing the code in-line (which is the typical Java pattern) for the priv-blocks?

        Show
        Daniel John Debrunner added a comment - Minor question on the code change (revision 586052). Is there any reason for creating two extra methods, rather than performing the code in-line (which is the typical Java pattern) for the priv-blocks?
        Hide
        Kathey Marsden added a comment -

        I just did it because to me it made the code easier to read.
        privInitialDirContext is called twice so it seemed better to have one method than duplicate the code. I can change them if you prefer.

        Kathey

        Show
        Kathey Marsden added a comment - I just did it because to me it made the code easier to read. privInitialDirContext is called twice so it seemed better to have one method than duplicate the code. I can change them if you prefer. Kathey
        Hide
        Daniel John Debrunner added a comment -

        If the priv block is used more than once in the same file then I agree it should probably be a method.

        For a single use I guess it's just a matter of preference, having the code in a separate method means that it's harder to read imho since one must look elsewhere instead of the code being right there.

        Show
        Daniel John Debrunner added a comment - If the priv block is used more than once in the same file then I agree it should probably be a method. For a single use I guess it's just a matter of preference, having the code in a separate method means that it's harder to read imho since one must look elsewhere instead of the code being right there.
        Kathey Marsden made changes -
        Resolution Fixed [ 1 ]
        Fix Version/s 10.3.1.5 [ 12312671 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 10.4.0.0 [ 12312540 ]
        Dag H. Wanvik made changes -
        Derby Categories [Security]
        Dag H. Wanvik made changes -
        Component/s Security [ 11411 ]
        Kathey Marsden made changes -
        Component/s Services [ 11415 ]
        Kathey Marsden made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Gavin made changes -
        Workflow jira [ 12346097 ] Default workflow, editable Closed status [ 12799919 ]

          People

          • Assignee:
            Kathey Marsden
            Reporter:
            Daniel John Debrunner
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development