db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Closed: (DERBY-1523) Statements in cache need to depend on privileges and the appropriate statements in cache should get invalidated if those privileges change.
Date Tue, 25 Jul 2006 20:26:15 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1523?page=all ]

Daniel John Debrunner closed DERBY-1523.
----------------------------------------

    Resolution: Invalid

I think there is an underlying issue here, but not exactly as described. Statements have a
set of permissions (StatementPermission objects) they require but since statements are shared
they cannot depend on a specific privilege (PermissionDescriptor instance). At runtime the
code checks the set of granted privileges against the required permissions to see if there
are sufficient granted privileges to proceed. Thus if a REVOKE SELECT privilege on T from
FRED and active SELECT against T need not be invalidated because it is still a valid plan.
A future execution by FRED may fail, but one by JANE might succed if JANE has been granted
SELCT on T.

Will enter a separate bug.

> Statements in cache need to depend on privileges and the appropriate statements in cache
should get invalidated if those privileges change.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1523
>                 URL: http://issues.apache.org/jira/browse/DERBY-1523
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.2.0.0
>            Reporter: Mamta A. Satoor
>             Fix For: 10.2.0.0
>
>
> In Derby SQL Standard Authorization model, statements need to keep track of what privileges
they depend on so that their plans can be later invalidated if those privileges are revoked.
This may happen once the revoke privilege (this includes explicit revoke privilege or indirect
revoke privilege action by dependency manager when the object on the privilege is granted
is dropped) work is all finished but I wanted to open a separate JIRA entry so we don't loose
track of statement caching.
> Currently, the last sql statement in following set of sql statements will raise a null
pointer exception
> connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta1' as mamta1;
> create table t11ConstraintTest (c111 int not null, c112 int not null, primary key (c111,
c112));
> grant references on t11ConstraintTest to mamta3;
> connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta3' as mamta3;
> drop table t31ConstraintTest;
> -- the following statement should remember that it depends on REFERENCES privilege on
mamta1.t11ConstraintTest 
> create table t31ConstraintTest (c311 int, c312 int, foreign key(c311, c312) references
mamta1.t11ConstraintTest);
> drop table t31ConstraintTest;
> set connection mamta1;
> -- following should revoke all the privileges granted on it
> drop table t11ConstraintTest;
> create table t11ConstraintTest (c111 int not null, c112 int not null, primary key (c111,
c112));
> grant references(c111) on t11ConstraintTest to mamta3;
> grant references(c112) on t11ConstraintTest to PUBLIC;
> --connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta3' as mamta3;
> set connection mamta3;
> drop table t31ConstraintTest;
> -- following sql should recompie itself because the earlier plan depended on a privilege
which doesn't
> -- exist anymore. Instead, new privileges have been granted and the plan for following
statement should depend
> -- on those new privileges
> create table t31ConstraintTest (c311 int, c312 int, foreign key(c311, c312) references
mamta1.t11ConstraintTest);
> All this work is in the langauge layer but I don't seem Language as one of the components
in JIRA hence I have put it in Miscellaneous category for now.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message