db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <ti...@espinhas.net>
Subject Re: Issues with SQL Roles
Date Tue, 14 Apr 2009 14:10:37 GMT
Hello Rick,

Thank you for your input. If that is expected then so much the better,
since it is not a bug.

Kathey, here's what I have so far:
http://docs.google.com/Doc?id=dgdrw3xt_3fp3pbngf

After some hiccups with the user documentation for SQL Roles (which
ended up being my fault), I managed to get the roles working without
the need to check any additional documentation. I also made some
functional tests (those on the doc.) and maybe I should/could make
them a JUnit test?

I'm also open to more suggestions for tests, stuff where the roles can
break so if anyone has any ideas I'd appreciate it.

Tiago

On Mon, Apr 13, 2009 at 4:02 PM, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> Hi Tiago,
>
> I believe that this behavior is deliberate and expected. I believe that
> permissions are not checked on every fetch from a ResultSet but that,
> instead, an in-flight ResultSet remains usable even though permissions may
> change after the ResultSet is opened. This, at least, is the sense I get
> from Dag's August 26, 2008 comment on
> http://issues.apache.org/jira/browse/DERBY-3223 Here's a quote from the
> comment:
>
> "Any open result sets will remain usable as before, since these remain
> open; even though the old (base)activation is no longer referenced
> from the GenericActivationHolder, there is a reference to the old
> activation from the result set, so it stays alive."
>
> Dag may want to comment further.
>
> Hope this helps,
> -Rick
>
>
> Tiago Espinha wrote:
>>
>> Hey everyone,
>>
>> I have been throwing tests at the SQL Roles. At this point I get a
>> certain behavior and perhaps Rick or Dag can give me some insight on
>> whether this is the expected behavior or if it is a bug.
>>
>> So, I'm not totally sure of how cursors work underneath, and I decided
>> to run a simple test:
>>
>> 1. Create the role testCursor with SELECT privileges on table t1
>> 2. Grant the role testCursor to the userTest
>> 3. With userTest get a cursor for t1
>> 4. Without closing the cursor, revoke the SELECT privileges to userTest
>> 5. Try to move the cursor forward
>>
>> Here the cursor keeps going until it reaches the end of the table;
>> this is, revoking the privileges doesn't affect the cursor. Is this
>> expected?
>>
>> Tiago
>>
>
>

Mime
View raw message