db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2893) INSERT and UPDATES succeed when permission has not been granted.
Date Mon, 09 Jul 2007 23:48:04 GMT

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

View raw message