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 "Rick Hillegas (JIRA)" <ji...@apache.org> on 2006/11/28 19:21:23 UTC

[jira] Updated: (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=all ]

Rick Hillegas updated DERBY-1716:
---------------------------------

    Fix Version/s: 10.2.2.0

Ported to 10.2 branch at subversion revision 480148.

> 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.6, 10.3.0.0, 10.2.2.0
>         Environment: Sun JDK 1.4.2
>            Reporter: Yip Ng
>         Assigned To: Yip Ng
>             Fix For: 10.3.0.0, 10.2.2.0
>
>         Attachments: derby1716-trunk-diff01a.txt, derby1716-trunk-diff02.txt, derby1716-trunk-diff03.txt, derby1716-trunk-stat01a.txt, derby1716-trunk-stat02.txt, derby1716-trunk-stat03.txt
>
>
> 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