db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4191) Lack of SELECT privilege does not prevent SELECT COUNT(*)
Date Fri, 04 Dec 2009 19:17:20 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mamta A. Satoor updated DERBY-4191:
-----------------------------------

    Attachment: DERBY4191_ColumnLevelCheckInStatmentColumnPerm_stat_patch2.txt
                DERBY4191_ColumnLevelCheckInStatmentColumnPerm_diff_patch2.txt

I am attaching a patch (DERBY4191_ColumnLevelCheckInStatmentColumnPerm_diff_patch2.txt)  is
same as the previous patch EXCEPT that the minimum select privilege requirement is enforced
in StatementColumnPermission rather than StatementTablePermission thus eliminating the need
to duplicate the code. 

I ran derbyall and junit tests and even with this patch, I continue to get the failure CheckToursDBTest:embeddedjunit.framework.AssertionFailedError:
org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif
In addition, I got one more failure, testReplication_Encrypted_1_miniLoad_negative(org.apache.derbyTesting.functio
nTests.tests.replicationTests.ReplicationRun_Local_Encrypted_1)junit.framework.ComparisonFailure:
Unexpected SQL state. expected:<...0> but was:<...1>

I reran the replication suite and didn't get the above failure when running this way.
$ java  -Dderby.tests.trace=true  -Xmx256M -XX:MaxPermSize=128M junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.replicationTests.Replication.Suite

If anyone has cycles at all, if they can run the junit suite with the patch I am attaching,
I will appreciate it. I want to be sure that nothing in my changes has broken the 2 failures
I am seeing(may be they are specific to my computer).  

Rick, thanks for reviwing my earlier patch. I agree with your comments about not trying to
selective handle specific select queries. As a next step, I will work on your suggestion of
requiring minimum select privilege on all the tables in the select query rather than trying
to handpick the ones based on select constant or select count(*) or select count(constant)
because this approach does not cover a query like select t1.c1 from anotheruser.t1, anotheruser.t2

I will post that patch once it is ready. 

> Lack of SELECT privilege does not prevent SELECT COUNT(*)
> ---------------------------------------------------------
>
>                 Key: DERBY-4191
>                 URL: https://issues.apache.org/jira/browse/DERBY-4191
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.4.2.0, 10.5.1.1
>            Reporter: Knut Anders Hatlen
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY4191_ColumnLevelCheckInStatmentColumnPerm_diff_patch2.txt,
DERBY4191_ColumnLevelCheckInStatmentColumnPerm_stat_patch2.txt, DERBY4191_ColumnLevelCheckInStatmentTablePerm_diff_patch1.txt,
DERBY4191_countStar_privilege_diff_patch1.txt, repro.sql
>
>
> A user that does not have SELECT privilege on a table can still perform a SELECT COUNT(*)
on that table. Counting a specific column (e.g., SELECT COUNT(X)) is prevented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message