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 "Yip Ng (JIRA)" <de...@db.apache.org> on 2006/09/20 19:19:25 UTC
[jira] Commented: (DERBY-1716) Revoking select privilege from a
user times out when that user still have a cursor open.
[ http://issues.apache.org/jira/browse/DERBY-1716?page=comments#action_12436281 ]
Yip Ng commented on DERBY-1716:
-------------------------------
The shared lock on SYS.SYSTABLEPERMS is actually obtained by the activation itself during
execution time (at the start of fillResultSet() of the activation class) since the grantee's privileges
are not in the permission cache yet. Thus, the shared locks will last till end of the transaction.
This is done once and those privileges that were loaded from the data dictionary(DD) will be stored
in the permission cache for use later so that the system does not need to load those info again
from the DD. Perhaps these privilege info can be loaded at compilation time instead as an improvement,
so that at execution time, privilege related metadata can be retrieved from the permission cache instead
of from the DD.
protected ResultSet fillResultSet() throws StandardException
{
((Activation) this).getLanguageConnectionContext().getAuthorizer().authorize( (Activation) this, 1 );
return getResultSetFactory().getScrollInsensitiveResultSet( <snip> );
}
> Revoking select privilege from a user times out when that user still have a cursor open.
> ----------------------------------------------------------------------------------------
>
> Key: DERBY-1716
> URL: http://issues.apache.org/jira/browse/DERBY-1716
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.1.0
> Environment: Sun JDK 1.4.2
> Reporter: Yip Ng
>
> Revoking table select privilege from a user will time out if that user still have an open cursor on that table.
> Hence, a database owner will not be able to revoke select privilege from any user(s) if they still have a cursor
> open. i.e.:
> ij version 10.2
> ij> connect 'jdbc:derby:cs1;create=true' user 'user1' as user1;
> WARNING 01J14: SQL authorization is being used without first enabling authentication.
> ij> connect 'jdbc:derby:cs1' user 'user3' as user3;
> WARNING 01J14: SQL authorization is being used without first enabling authentication.
> ij(USER3)> set connection user1;
> ij(USER1)> create table t1001 (c varchar(1));
> 0 rows inserted/updated/deleted
> ij(USER1)> insert into t1001 values 'a', 'b', 'c';
> 3 rows inserted/updated/deleted
> ij(USER1)> grant select on t1001 to user3;
> 0 rows inserted/updated/deleted
> ij(USER1)> set connection user3;
> ij(USER3)> autocommit off;
> ij(USER3)> GET CURSOR crs1 AS 'select * from user1.t1001';
> ij(USER3)> next crs1;
> C
> ----
> a
> ij(USER3)> set connection user1;
> ij(USER1)> -- revoke select privilege while user3 still have an open cursor
> revoke select on t1001 from user3;
> ERROR 40XL1: A lock could not be obtained within the time requested
> ij(USER1)> select * from syscs_diag.lock_table;
> XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|LOCK&|INDEXNAME
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 130 |TABLE|IS |SYSTABLEPERMS |Tablelock |GRANT|S |4 |NULL
> 130 |ROW |S |SYSTABLEPERMS |(1,7) |GRANT|S |2 |NULL
> 130 |TABLE|IS |T1001 |Tablelock |GRANT|T |1 |NULL
> 3 rows selected
> ij(USER1)> set connection user3;
> ij(USER3)> next crs1;
> C
> ----
> b
> ij(USER3)> next crs1;
> C
> ----
> c
> ij(USER3)> close crs1;
> ij(USER3)>
> Is there a reason why Derby still keep shared locks on SYS.SYSTABLEPERMS during fetch?
> sysinfo:
> ------------------ Java Information ------------------
> Java Version: 1.4.2_12
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\j2re1.4.2_12
> Java classpath: derby.jar;derbytools.jar
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: Yip
> Java user home: C:\Documents and Settings\Yip
> Java user dir: C:\work3\derby\tests\derby-10.2.1.0\lib
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> --------- Derby Information --------
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [C:\work3\derby\tests\derby-10.2.1.0\lib\derby.jar] 10.2.1.0 beta - (430903)
> [C:\work3\derby\tests\derby-10.2.1.0\lib\derbytools.jar] 10.2.1.0 beta - (430903)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale : [English/United States [en_US]]
> Found support for locale: [de_DE]
> version: 10.2.1.0 - (430903)
> Found support for locale: [es]
> version: 10.2.1.0 - (430903)
> Found support for locale: [fr]
> version: 10.2.1.0 - (430903)
> Found support for locale: [it]
> version: 10.2.1.0 - (430903)
> Found support for locale: [ja_JP]
> version: 10.2.1.0 - (430903)
> Found support for locale: [ko_KR]
> version: 10.2.1.0 - (430903)
> Found support for locale: [pt_BR]
> version: 10.2.1.0 - (430903)
> Found support for locale: [zh_CN]
> version: 10.2.1.0 - (430903)
> Found support for locale: [zh_TW]
> version: 10.2.1.0 - (430903)
> ------------------------------------------------------
--
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