Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <25741869.1184024884480.JavaMail.jira@brutus>
Date: Mon, 9 Jul 2007 16:48:04 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2893) INSERT and UPDATES succeed when
 permission has not been granted.
In-Reply-To: <5594754.1183484344510.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kathey Marsden commented on DERBY-2893:
---------------------------------------

I wonder if the order of the decorators in the setup of this test has anything to do with the issue.
We have:
public static Test basesuite() {
		Test basesuite = new TestSuite(GrantRevokeTest.class);
		Test clean = new CleanDatabaseTestSetup(basesuite) {
	    	protected void decorateSQL(Statement s) throws SQLException {
	    		s.execute("create schema s1");
	    		s.execute("create schema s2");
                       ....
                     }

		Test test = DatabasePropertyTestSetup.builtinAuthentication(
				clean, users, "grantrevoke");
        test = TestConfiguration.sqlAuthorizationDecorator(test);
	    

Does this mean that decorateSQL will run before sqlAuthorization is enabled, meaning the tables don't have the necessary permission restrictions?  I haven't yet gotten the order successfully reversed but this is my current theory.

I verified manually that grant/revoke on all privileges (which is one of the cases failing) works ok, so I tend to think it is a test issue, but have not completely confirmed this yet.


> INSERT and UPDATES succeed when permission has not been granted.
> ----------------------------------------------------------------
>
>                 Key: DERBY-2893
>                 URL: https://issues.apache.org/jira/browse/DERBY-2893
>             Project: Derby
>          Issue Type: Bug
>          Components: Security, SQL
>    Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0
>            Reporter: Daniel John Debrunner
>            Priority: Critical
>
> GrantRevokeTest had assert methods (assertInsertPrivilege etc.) of the form
> try {
>    s.execute(command)
> } catch (SQLException sqle)
> {
>        if (!hasPrivilege) 
>             assertSQLState("42502", e);
>        else
>              fail(...);
> }
> Note that no fail() assert was in the try portion after the SQL execution. The statement should not work if hasPrivilege is false, but the test will incorrectly pass if the statement succeeds. I added fail asserts with revision 552922 like:
> if (!hasPrivilege)
>        fail("expected no INSERT permission on table");
> but these two for INSERT and UPDATE caused the test to fail (about 6 fixtures fail) indicating that the statement succeeds even if the permission is not granted.
> It could be a test problem but needs some investigation.
> The asserts for assertInsertPrivilege and asserUpdatePrivilege are commented out to stop the test failing.

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