Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 32345 invoked from network); 20 Sep 2006 23:20:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Sep 2006 23:20:17 -0000 Received: (qmail 56548 invoked by uid 500); 20 Sep 2006 23:20:17 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 56511 invoked by uid 500); 20 Sep 2006 23:20:17 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 56496 invoked by uid 99); 20 Sep 2006 23:20:17 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Sep 2006 16:20:17 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from [209.237.227.198] ([209.237.227.198:37838] helo=brutus.apache.org) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id DD/F1-04092-8ACC1154 for ; Wed, 20 Sep 2006 16:20:08 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 904E77142F2 for ; Wed, 20 Sep 2006 23:16:23 +0000 (GMT) Message-ID: <25528931.1158794183588.JavaMail.jira@brutus> Date: Wed, 20 Sep 2006 16:16:23 -0700 (PDT) From: "Bryan Pendleton (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-1716) Revoking select privilege from a user times out when that user still have a cursor open. In-Reply-To: <19439240.1155846433848.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1716?page=comments#action_12436391 ] Bryan Pendleton commented on DERBY-1716: ---------------------------------------- Yip, are you saying that we use the *user's* transaction to read table and column permissions information from the data dictionary? I would have expected us to use some sort of internal "system" transaction for this kind of catalog fetch. > 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