You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2008/05/20 20:45:56 UTC

[jira] Created: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

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




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-3681:
---------------------------------

    Derby Info: [Patch Available]

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


[jira] Updated: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-3681:
---------------------------------

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

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


[jira] Updated: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-3681:
---------------------------------

    Attachment: derby-3681-1.stat
                derby-3681-1.diff

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.


[jira] Resolved: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik resolved DERBY-3681.
----------------------------------

    Resolution: Fixed
    Derby Info:   (was: [Patch Available])

Thanks, Knut. Committed patch derby-3681-2 as svn 659543, resolving.

> 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, derby-3681-2.diff, derby-3681-2.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.


[jira] Closed: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik closed DERBY-3681.
--------------------------------


> 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, derby-3681-2.diff, derby-3681-2.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.


[jira] Commented: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599285#action_12599285 ] 

Knut Anders Hatlen commented on DERBY-3681:
-------------------------------------------

The changes in derby-3681-2 look good. Thanks Dag! +1 to commit.

> 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, derby-3681-2.diff, derby-3681-2.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.


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

Posted by "Dag H. Wanvik (JIRA)" <ji...@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.


[jira] Commented: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598953#action_12598953 ] 

Knut Anders Hatlen commented on DERBY-3681:
-------------------------------------------

Hi Dag,

The code in EmbedConnection looks good. One minor nit: @code{lcc} in the javadoc should have been {@code lcc}, I think. And, by the way, would it make sense to hide the version check in a helper method, for instance dd.supportsRoles()? I don't know how we usually check the dictionary version.

I'm not sure that the change in DriverManagerConnector is correct. Using the default user ensures that the DBO is the same regardless of whether the database was created in that test or not. Not sure if this matters to any of the tests, though, I just wanted to raise the issue.

In RolesTest, I think this code should be simplified:

+            Connection cn = null;
+            try {
+                // should work, not defined as a role yet
+                cn = openDefaultConnection("soonarole","whatever");
+            } finally {
+                try {
+                    if (cn != null) {
+                        cn.close();
+                    }
+                } catch (SQLException e) {
+                }
+            }

As it is now, if openDefaultConnection() incorrectly returns null, it is silently ignored. Also, exceptions from cn.close() are swallowed. Couldn't it be replaced with this one-liner:

    openDefaultConnection("soonarole", "whatever").close();

It's simpler, and it would fail on null values and SQLExceptions. (For readability, I would perhaps also have removed the finally clause in the try/finally near the end of testLoginWithUsernameWhichIsARole() too, but there it wouldn't have any effect on what is tested.)

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


[jira] Updated: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-3681:
---------------------------------

    Attachment: derby-3681-2.stat
                derby-3681-2.diff

derby-3681-2 addresses Knuts comments for RoleTest.
Regressions ran OK for version 1 of the patch, and I tested RolesTest over again,
so if there are no further comments it should be ready for commit.

> 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, derby-3681-2.diff, derby-3681-2.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.


[jira] Commented: (DERBY-3681) When authenticating a user at connect time, verify that the user provided is not also a defined role name.

Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DERBY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599117#action_12599117 ] 

Dag H. Wanvik commented on DERBY-3681:
--------------------------------------

Thanks for comments, Knut! The RolesTest simplifications are nice :)

> I'm not sure that the change in DriverManagerConnector is correct. 
> Using the default user ensures that the DBO is the > same regardless
> of whether the database was created in that test or not. Not sure if this 
> matters to any of the tests, though, I just wanted to raise the issue.

Yes I did consider this, but felt it was an very weird way of creating the database and the connection returned would be with another current user than the one requested, which seems plain wrong to me. Anyway, I ran the regression
tests successfully, so it seems this behavior is not counted upon.

As far as checking the dictionary verision, it seems DataDictionary#checkVersion  is the one to use. The parser uses this, too. Interestingly, if the feature supplied is non-null it throws if the version is not new enough, if the
feature is null, it returns false...Struck me as a bit odd.

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