Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 15014 invoked from network); 21 May 2008 21:46:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 May 2008 21:46:17 -0000 Received: (qmail 59024 invoked by uid 500); 21 May 2008 21:46:19 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 58809 invoked by uid 500); 21 May 2008 21:46:18 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 58794 invoked by uid 99); 21 May 2008 21:46:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 14:46:18 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 21:45:40 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id CB545234C11E for ; Wed, 21 May 2008 14:45:55 -0700 (PDT) Message-ID: <1591634360.1211406355831.JavaMail.jira@brutus> Date: Wed, 21 May 2008 14:45:55 -0700 (PDT) From: "Dag H. Wanvik (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Issue Comment Edited: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name. In-Reply-To: <711980761.1211309156309.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598799#action_12598799 ] dagw edited comment on DERBY-3681 at 5/21/08 2:44 PM: --------------------------------------------------------------- Uploading patch derby-3681-1 which implements the check. Running regression tests now. Patch details: M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java An extra test is added to checkUserCredentials when applicable (dictionary >= 10.4 and sqlAuthorization is in use). A user name which equals a role name will lead to connection level exception state NET_CONNECT_AUTH_FAILED, i.e. 08004 and the connect will fail. I chose not to add a new error message here, in the spirit of not providing too much information when authentication fails. Admittedly, this could cause some user confusion ("this user is defined, why can't I connect?"), so a more helpful message is arguably better. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesTest.java Added a test case for the new check. M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java For the client, openConnection(String, String, String) can't reliably determine if a 08004 means the database does not exist or if it is a authentication problem, so before this fix, my new test failed because the fallback here tried to create a new database in such cases. This should also fail when using the provided user, but it did not, since the fallback used a call to getConnectionByAttributes(url, "create", "true"). This uses the default user, not the one provided. So i modified this code to try to create using the provided user which seems more logical anyway.. M java/testing/org/apache/derbyTesting/junit/CleanDatabaseTestSetup.java Added code to remove any roles when cleaning a database. This was necessary since the RolesTest left a role in the database called "bar", which the subsequent SQLGrantREvokeDDLTest tried to use as a user name. The new check introduced with this issue made that fail. was (Author: dagw): Uploading patch derby-3681-1 which implements the check. Running regression tests now. Patch details: M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java An extra test is added to checkUserCredentials when applicable (dictionary >= 10.4 and sqlAuthorization is in use). A user name which equals a role name will lead to connection level exception state NET_CONNECT_AUTH_FAILED, i.e. 08004 and the connect will fail. I chose not to add a new error message here, in the spirit of not providing too much information when authentication fails. Admittedly, this could cause some user confusion ("this user is defined, why can't I connect?"), so a more helpful message is arguably better. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesTest.java Added a test case for the new check. M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java For the client, openConnection(String, String, String) can't reliably determine if a 08004 means the database does not exist or if it is a authentication problem, so before this fix, my new test failed because the fallback here tried to create a new database in such cases. Thus should also when using the provided user, but it did not, since the fallback used a call to getConnectionByAttributes(url, "create", "true"); which uses the default user, not the one provided, which I want to fail. So i modified this code to try to create using the provided user which seems more logical anyway.. M java/testing/org/apache/derbyTesting/junit/CleanDatabaseTestSetup.java Added code to remove any roles when cleaning a database. This was necessary since the RolesTest left a role in the database called "bar", which the subsequent SQLGrantREvokeDDLTest tried to use as a user name. The new check introduced with this issue made that fail. > When authenticating a user at connect time, verify that the user provided is not also a defined role name. > ---------------------------------------------------------------------------------------------------------- > > Key: DERBY-3681 > URL: https://issues.apache.org/jira/browse/DERBY-3681 > Project: Derby > Issue Type: Sub-task > Components: Security > Reporter: Dag H. Wanvik > Assignee: Dag H. Wanvik > Fix For: 10.5.0.0 > > Attachments: derby-3681-1.diff, derby-3681-1.stat > > > Although we try to avoid creating role that are not also valid Derby users (see DERBY-3673), we cannot > in general know for sure that no such user exists; it could be added to derby.properties after > the role has been created, authentication could be LDAP or user-defined, in which cases > the check at role creation time will not work. So, in order to avoid collisions between user identifiers and role identifiers, we shoudl check at connect time that there is no role by same name as the supplied user name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.