Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 53304 invoked from network); 30 Aug 2006 22:20:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Aug 2006 22:20:55 -0000 Received: (qmail 37456 invoked by uid 500); 30 Aug 2006 22:20:55 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 37234 invoked by uid 500); 30 Aug 2006 22:20:54 -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 37225 invoked by uid 99); 30 Aug 2006 22:20:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Aug 2006 15:20:54 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Aug 2006 15:20:54 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 81F7741001D for ; Wed, 30 Aug 2006 22:17:24 +0000 (GMT) Message-ID: <7633469.1156976244530.JavaMail.jira@brutus> Date: Wed, 30 Aug 2006 15:17:24 -0700 (PDT) From: "Mamta A. Satoor (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-1686) Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail In-Reply-To: <5962508.1155358093826.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1686?page=comments#action_12431728 ] Mamta A. Satoor commented on DERBY-1686: ---------------------------------------- Yip, the latest patch looks pretty good to me. Just 2 minor comments 1)In code comments, I saw references to "dba". I think we want to refer to that user as "database owner". Dan had mentioned following in one of his emails to derby dev list "DBA is a role (which doesn't (yet) exist in Derby)." 2)Secondly, can you please verify that the existing comments in the grant revoke test still make sense around the areas where you had to make changes to the test because of the functionality implemented by this Jira entry. Thanks for being so patient with my feedback on this Jira entry. > Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail > ------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1686 > URL: http://issues.apache.org/jira/browse/DERBY-1686 > Project: Derby > Issue Type: Bug > Components: SQL > Affects Versions: 10.2.1.0 > Environment: Any > Reporter: Rajesh Kartha > Assigned To: Yip Ng > Fix For: 10.2.1.0 > > Attachments: derby1686-trunk-diff01.txt, derby1686-trunk-diff02.txt, derby1686-trunk-diff03.txt, derby1686-trunk-diff04.txt, derby1686-trunk-diff05.txt, derby1686-trunk-stat01.txt, derby1686-trunk-stat02.txt, derby1686-trunk-stat03.txt, derby1686-trunk-stat04.txt, derby1686-trunk-stat05.txt, select_table_no_privilege.sql > > > With authentication on, attempting to execute a GRANT privilege to 'user3' on a VIEW created by the 'user2' - who has only SELECT privilege > on the base table created by 'user1' does not fail. This results in 'user3' getting access to the table created by 'user1' through the view. > I remember a discussion on the list to raise an error when an attempt is execute a GRANT on the view, until WITH GRANT option is implemented. > Here is the repro: > java -cp derby.jar;.\derbytools.jar -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij select_table_no_privilege.sql > ij version 10.2 > ij> -- > --create db as user1 > -- > connect 'jdbc:derby:grntrevokedb;create=true' user 'user1'; > WARNING 01J14: SQL authorization is being used without first enabling authentication. > ij> create table t1(id int); > 0 rows inserted/updated/deleted > ij> insert into t1 values(100); > 1 row inserted/updated/deleted > ij> insert into t1 values(200); > 1 row inserted/updated/deleted > ij> -- > --Grant select to user2 > -- > grant select on t1 to user2; > 0 rows inserted/updated/deleted > ij> -- > --Connect as user2 > -- > connect 'jdbc:derby:grntrevokedb;create=true' user 'user2'; > WARNING 01J01: Database 'grntrevokedb' not created, connection made to existingdatabase instead. > WARNING 01J14: SQL authorization is being used without first enabling authentication. > ij(CONNECTION1)> select * from user1.t1; > ID > ----------- > 100 > 200 > 2 rows selected > ij(CONNECTION1)> -- > --Create view > -- > create view v1 as select * from user1.t1; > 0 rows inserted/updated/deleted > ij(CONNECTION1)> select * from v1; > ID > ----------- > 100 > 200 > 2 rows selected > ij(CONNECTION1)> -- > --Grant select on view to user3. With the WITH GRANT option this should have failed > -- > grant select on v1 to user3; > 0 rows inserted/updated/deleted > ij(CONNECTION1)> -- > --Connect as user3 > -- > connect 'jdbc:derby:grntrevokedb;create=true' user 'user3'; > WARNING 01J01: Database 'grntrevokedb' not created, connection made to existing > database instead. > WARNING 01J14: SQL authorization is being used without first enabling authentication. > ij(CONNECTION2)> -- > --No select privilege on base table user1.t1, hence will FAIL > -- > select * from user1.t1; > ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. > ERROR 28508: User 'USER3' does not have select permission on column 'ID' of table 'USER1'.'T1'. > at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) > at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(Unknown Source) > at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(Unknown Source) > at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax00000011df100.fillResultSet(Unknown Source) > at org.apache.derby.exe.ac295dc08bx010dx00a2x500ax00000011df100.execute(Unknown Source) > at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) > at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) > at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) > at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) > at org.apache.derby.tools.ij.main(Unknown Source) > ij(CONNECTION2)> -- > --Select from the view on the base table should also FAIL, but does not > -- > select * from user2.v1; > ID > ----------- > 100 > 200 > 2 rows selected > ij(CONNECTION2)> -- 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