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 Dy...@Sun.COM on 2007/04/03 15:13:09 UTC
Question about grant/revoke
While working on re-using resultsets (DERBY-827) I've discovered that
calls to
getLanguageConnectionContext().getAuthorizer().authorize(this , 1);
have been added in places that I don't think are compatible with
re-using result sets.
One example is the following decompiled byte code fragment which shows
that for prepared statements authorization will be done on the first
execution, only (this is WITH the DERBY-827 patch applied).
public ResultSet execute()
throws StandardException
{
throwIfClosed("execute");
startExecution();
BaseActivation.reinitializeQualifiers(e2);
return ((resultSet == null) ? fillResultSet() : resultSet);
// Oops, will not call fillResultSet() on later executions
}
private ResultSet fillResultSet()
throws StandardException
{
getLanguageConnectionContext().getAuthorizer().authorize(this , 1);
// Problem - can't check authorization here, will not get called when
// ps is re-executed
return (getResultSetFactory().getScrollInsensitiveResultSet(getResultSetFactory().getIndexRowToBaseRowResultSet((long)960 , 5 , getResultSetFactory().getTableScanResultSet(this , (long)977 , 7 , getMethod("e0") , 2 , getMethod("e1") , 1 , null , -1 , true , e2 , "T1" , null , "SQL070402062141340" , true , false , -1 , -1 , 6 , false , 0 , true , 1.0 , 5.1195) , getMethod("e2") , 1 , "T1" , 1 , 2 , 3 , 4 , null , false , 1.0 , 5.1195) , this , 0 , 2 , getScrollable() , 1.0 , 5.1195));
}
This causes failures in derbyall when running with the DERBY-827 patch.
There is also the following code in GenericResultSetFactory
public ResultSet getDDLResultSet(Activation activation)
throws StandardException
{
getAuthorizer(activation).authorize(activation, Authorizer.SQL_DDL_OP);
return getMiscResultSet( activation);
}
which checks authorization when the DDL/Misc result set is created,
and not when it is opened.
I've not seen a failure caused by this, but I suspect it is a problem.
Do the grant/revoke experts have an opinion about how to fix this?
I'm thinking that the byte code could be changed so that authorization
is done in execute() rather than fillResultSet(), and that the
DDL/Misc check could be deferred to open(). Will that work?
--
dt
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Mamta Satoor <ms...@gmail.com> writes:
> When a revoke is issued, Derby sends an
> DependencyManager.REVOKE_PRIVILEGEinvalidation to dependents of the
> privilege being revoked. Bryan's
> suggestion is a sure shot to not miss any statments but like he pointed out,
> that will end up invalidating statements that are not affected by the revoke
> privilege.
Thanks Mamta, Bryan and Dan for your comments.
DependencyManager.REVOKE_PRIVILEGE seems like just the starting point
I was looking for. Thanks.
--
dt
Re: Question about grant/revoke
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> a re-compile, which in turn should fail because I no longer have
> select privilege on T.
There's a little bit of information about these topics in the
wiki at: http://wiki.apache.org/db-derby/GrantRevokeImplementation
Maybe that page has some useful pointers or clues?
thanks,
bryan
Re: Question about grant/revoke
Posted by Daniel John Debrunner <dj...@apache.org>.
Dyre.Tjeldvoll@Sun.COM wrote:
> Daniel John Debrunner <dj...@apache.org> writes:
>
>> The privilege checking should occur when creating the Activation which
>> is when the plan (shared) gets hooked up to the specific user's
>> java.sql.PreparedStatement. This is what happens today, but then
>> Activations are not re-used across re-executions of the same
>> java.sql.PreparedStatement.
>>
>> Thus it's fine (should be :-) if multiple users are sharing the same plan.
>>
>> I think for simple statements like SELECT * FROM T then the plan
>> should be dependent on T (which it will be) and the REVOKE
>> invalidation should be against T, not a privilege related to T. This
>> then indicates that the privilege set for that table has changed and
>> so any user must re-check its privileges. With the current code this
>> would invalidate the plan which I don't think is a problem since
>> REVOKE statements are not expected to be frequent. Ideally the revoke
>> would just mark current activations as needing to re-check privileges,
>> but I'm not sure if that complication is worth it for REVOKE.
>
> I have created
>
> https://issues.apache.org/jira/browse/DERBY-2594
>
> to track this.
>
>> Thus maybe the bug is when a privilege is revoked an invalidation
>> against the object is was granted on is not being sent. I wonder if
>> there are existing bugs due to this, which would encourage fixing it
>> before changing the current correct privilege checking to something
>> "incorrect" only to revert it later.
>
> I basically agree, but I'm worried that requiring DERBY-2594 to be fixed
> before proceeding with DERBY-827, could mean that neither make it into
> 10.3. And I'll admit that it is a personal itch of mine to get
> DERBY-827 in, if at all possible.
Yes, I see the concern & I'd like to see DERBY-827 in 10.3, but it just
seems wrong if the fix to DERBY-827 involves making things occur once
per execution when the point of the issue to to stop things occurring
per-execution. :-)
I'll help out on the invalidation as I can since I'm already looking in
that area for DERBY-2380.
Dan.
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Daniel John Debrunner <dj...@apache.org> writes:
> The privilege checking should occur when creating the Activation which
> is when the plan (shared) gets hooked up to the specific user's
> java.sql.PreparedStatement. This is what happens today, but then
> Activations are not re-used across re-executions of the same
> java.sql.PreparedStatement.
>
> Thus it's fine (should be :-) if multiple users are sharing the same plan.
>
> I think for simple statements like SELECT * FROM T then the plan
> should be dependent on T (which it will be) and the REVOKE
> invalidation should be against T, not a privilege related to T. This
> then indicates that the privilege set for that table has changed and
> so any user must re-check its privileges. With the current code this
> would invalidate the plan which I don't think is a problem since
> REVOKE statements are not expected to be frequent. Ideally the revoke
> would just mark current activations as needing to re-check privileges,
> but I'm not sure if that complication is worth it for REVOKE.
I have created
https://issues.apache.org/jira/browse/DERBY-2594
to track this.
> Thus maybe the bug is when a privilege is revoked an invalidation
> against the object is was granted on is not being sent. I wonder if
> there are existing bugs due to this, which would encourage fixing it
> before changing the current correct privilege checking to something
> "incorrect" only to revert it later.
I basically agree, but I'm worried that requiring DERBY-2594 to be fixed
before proceeding with DERBY-827, could mean that neither make it into
10.3. And I'll admit that it is a personal itch of mine to get
DERBY-827 in, if at all possible.
Fww. I have assigned myself to DERBY-2594 and I will try to get it
ready for 10.3, but since I'm going to JavaOne I don't have that much
time before the proposed deadline.
> It's possible for views/triggers that they would need to depend on a
> specific privilege, rather than just the table, because of the rules
> of dropping such items when the privilege is revoked. Thus the
> invalidation based upon the privilege may still be needed.
--
dt
Re: Question about grant/revoke
Posted by Daniel John Debrunner <dj...@apache.org>.
Dyre.Tjeldvoll@Sun.COM wrote:
> Mamta Satoor <ms...@gmail.com> writes:
>
>> One thing that comes to my mind with privilege checking only at first
>> execution is will it be a problem if different users execute the same
>> statement? Will we be able to know that even if the statement has already
>> been executed once, we should do the privilege checking because this time,
>> it is a different user who is executing the statement.
>
> Uhhh, dunno :) A valid question for which I don't have an answer. Hmm,
> Knut's suggestion about factoring this out in separate jira is looking
> more and more appealing. Especially if it could wait until after
> 10.3 when we all would have more free cycles (I hope).
The privilege checking should occur when creating the Activation which
is when the plan (shared) gets hooked up to the specific user's
java.sql.PreparedStatement. This is what happens today, but then
Activations are not re-used across re-executions of the same
java.sql.PreparedStatement.
Thus it's fine (should be :-) if multiple users are sharing the same plan.
I think for simple statements like SELECT * FROM T then the plan should
be dependent on T (which it will be) and the REVOKE invalidation should
be against T, not a privilege related to T. This then indicates that the
privilege set for that table has changed and so any user must re-check
its privileges. With the current code this would invalidate the plan
which I don't think is a problem since REVOKE statements are not
expected to be frequent. Ideally the revoke would just mark current
activations as needing to re-check privileges, but I'm not sure if that
complication is worth it for REVOKE.
Thus maybe the bug is when a privilege is revoked an invalidation
against the object is was granted on is not being sent. I wonder if
there are existing bugs due to this, which would encourage fixing it
before changing the current correct privilege checking to something
"incorrect" only to revert it later.
It's possible for views/triggers that they would need to depend on a
specific privilege, rather than just the table, because of the rules of
dropping such items when the privilege is revoked. Thus the invalidation
based upon the privilege may still be needed.
Dan.
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Mamta Satoor <ms...@gmail.com> writes:
> Thanks for giving me the background info, Dyre. I see now the problem you
> are trying to address. With the collation work, I haven't been able to keep
> up with the list and so was not aware of the background of this thread.
Quite understandable :)
> One thing that comes to my mind with privilege checking only at first
> execution is will it be a problem if different users execute the same
> statement? Will we be able to know that even if the statement has already
> been executed once, we should do the privilege checking because this time,
> it is a different user who is executing the statement.
Uhhh, dunno :) A valid question for which I don't have an answer. Hmm,
Knut's suggestion about factoring this out in separate jira is looking
more and more appealing. Especially if it could wait until after
10.3 when we all would have more free cycles (I hope).
--
dt
Re: Question about grant/revoke
Posted by Mamta Satoor <ms...@gmail.com>.
Thanks for giving me the background info, Dyre. I see now the problem you
are trying to address. With the collation work, I haven't been able to keep
up with the list and so was not aware of the background of this thread.
One thing that comes to my mind with privilege checking only at first
execution is will it be a problem if different users execute the same
statement? Will we be able to know that even if the statement has already
been executed once, we should do the privilege checking because this time,
it is a different user who is executing the statement.
Mamta
On 4/24/07, Dyre.Tjeldvoll@sun.com <Dy...@sun.com> wrote:
>
> Mamta Satoor <ms...@gmail.com> writes:
>
> > Dyre, I don't remember now if we discussed the 2 possible implementation
>
> > choices ie to invalidate prepared statements by making them depend on
> > privileges needed vs just catch privilege revocation at prepared
> statement
> > execute time. I wonder if there is anything in the Derby dev list
> archive
> > about this.
>
> Again, thanks for taking the time to look at this. I'll scan the
> archives and see what I can find.
>
> > It seems like though that privilege revocation does get caught at
> execute
> > time with the current implementation.
>
> Yes, but it happens inside fillResultSet(). Currently that method gets
> called on every execution, but we are (DERBY-827) trying to make it
> happen only on the first execution.
>
> > Does that approach not work in some circumstances and is that why we
> > are disucssing that approach?
>
> It works just fine. I've tested modifying the call to
>
> generateAuthorizeCheck()
>
> so that it adds its code to execute(), rather
> than fillResultSet(), and this makes the test pass (and I haven't
> noticed any negative side effects).
>
> However, Dan wrote earlier in this thread (Tue, 03 Apr 2007 07:07:40
> -0700):
>
> "I think that the checking authorization once is the desired behaviour,
> not every execution, for performance reasons. The statements should be
> invalidated when a revoke is executed."
>
> So that's why I'm looking at this...
>
> --
> dt
>
>
Re: Question about grant/revoke
Posted by Kn...@Sun.COM.
Dyre.Tjeldvoll@Sun.COM writes:
> It works just fine. I've tested modifying the call to
>
> generateAuthorizeCheck()
>
> so that it adds its code to execute(), rather
> than fillResultSet(), and this makes the test pass (and I haven't
> noticed any negative side effects).
>
> However, Dan wrote earlier in this thread (Tue, 03 Apr 2007 07:07:40
> -0700):
>
> "I think that the checking authorization once is the desired behaviour,
> not every execution, for performance reasons. The statements should be
> invalidated when a revoke is executed."
>
> So that's why I'm looking at this...
Checking the permissions once per execution is perhaps not ideal, but if
that's how it's currently done, I don't see any problem with moving the
check from fillResultSet() to execute() as part of DERBY-827. Although
"check once and invalidate on revoke" might give better performance, it
could just as well be addressed later in a separate JIRA issue.
--
Knut Anders
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Mamta Satoor <ms...@gmail.com> writes:
> Dyre, I don't remember now if we discussed the 2 possible implementation
> choices ie to invalidate prepared statements by making them depend on
> privileges needed vs just catch privilege revocation at prepared statement
> execute time. I wonder if there is anything in the Derby dev list archive
> about this.
Again, thanks for taking the time to look at this. I'll scan the
archives and see what I can find.
> It seems like though that privilege revocation does get caught at execute
> time with the current implementation.
Yes, but it happens inside fillResultSet(). Currently that method gets
called on every execution, but we are (DERBY-827) trying to make it
happen only on the first execution.
> Does that approach not work in some circumstances and is that why we
> are disucssing that approach?
It works just fine. I've tested modifying the call to
generateAuthorizeCheck()
so that it adds its code to execute(), rather
than fillResultSet(), and this makes the test pass (and I haven't
noticed any negative side effects).
However, Dan wrote earlier in this thread (Tue, 03 Apr 2007 07:07:40
-0700):
"I think that the checking authorization once is the desired behaviour,
not every execution, for performance reasons. The statements should be
invalidated when a revoke is executed."
So that's why I'm looking at this...
--
dt
Re: Question about grant/revoke
Posted by Mamta Satoor <ms...@gmail.com>.
Dyre, I don't remember now if we discussed the 2 possible implementation
choices ie to invalidate prepared statements by making them depend on
privileges needed vs just catch privilege revocation at prepared statement
execute time. I wonder if there is anything in the Derby dev list archive
about this.
It seems like though that privilege revocation does get caught at execute
time with the current implementation. Does that approach not work in some
circumstances and is that why we are disucssing that approach?
Mamta
On 4/24/07, Dyre.Tjeldvoll@sun.com <Dy...@sun.com> wrote:
>
> Mamta Satoor <ms...@gmail.com> writes:
>
> > Dyre, before I can understand the entire email, I need understanding
> this
> > part of your mail
> > "Assume I have a table T and a view V that references it, and that I
> > currently have select privilege on T." Who owns the table T when you say
> I
> > have a table T? Also, let me take the case where you are not the owner
> of
> > table T and you have been granted select privilege on T, then you don't
> > automatically get select privilege on view V. In that case, this
> statement
> > doesn't sound right "I currently have select privilege on T. Assume that
> I
> > have created a prepared statement P that selects from V." If you have
> select
> > privileges on T only, then you should not be able to preapre a statement
> > which selects from V. So, it will be good to know the exact ownership of
> the
> > objects and the exact privileges granted to the user who is trying to
> > prepare a statement.
>
> Thanks for precious time from your collation work to answer my
> question :)
> (If anyone else knows the answer to these questions it
> would probably be good if they could help Mamta out :)
>
> OK, I think I have confused things a bit. Forget the view (don't think
> it is relevant), and assume that P references T directly. Assume that
> some other user X created T and has granted me select privilege on T.
> I prepare P without problems and execute it. Then user X revokes my select
> privilege on T. I then try to execute P again.
>
> My understanding (based on Dan's comments earlier in this thread and
> in DERBY-827) is that P then should already have been marked as
> invalid by the revoke and that my attempt to execute P should trigger
> a re-compile, which in turn should fail because I no longer have
> select privilege on T.
>
> (This isn't what happens today btw. Currently P will not be invalid,
> but it checks that it has the necessary permissions on every execute,
> so the second execute of P will still fail)
>
> --
> dt
>
>
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Mamta Satoor <ms...@gmail.com> writes:
> Dyre, before I can understand the entire email, I need understanding this
> part of your mail
> "Assume I have a table T and a view V that references it, and that I
> currently have select privilege on T." Who owns the table T when you say I
> have a table T? Also, let me take the case where you are not the owner of
> table T and you have been granted select privilege on T, then you don't
> automatically get select privilege on view V. In that case, this statement
> doesn't sound right "I currently have select privilege on T. Assume that I
> have created a prepared statement P that selects from V." If you have select
> privileges on T only, then you should not be able to preapre a statement
> which selects from V. So, it will be good to know the exact ownership of the
> objects and the exact privileges granted to the user who is trying to
> prepare a statement.
Thanks for precious time from your collation work to answer my
question :)
(If anyone else knows the answer to these questions it
would probably be good if they could help Mamta out :)
OK, I think I have confused things a bit. Forget the view (don't think
it is relevant), and assume that P references T directly. Assume that
some other user X created T and has granted me select privilege on T.
I prepare P without problems and execute it. Then user X revokes my select
privilege on T. I then try to execute P again.
My understanding (based on Dan's comments earlier in this thread and
in DERBY-827) is that P then should already have been marked as
invalid by the revoke and that my attempt to execute P should trigger
a re-compile, which in turn should fail because I no longer have
select privilege on T.
(This isn't what happens today btw. Currently P will not be invalid,
but it checks that it has the necessary permissions on every execute,
so the second execute of P will still fail)
--
dt
Re: Question about grant/revoke
Posted by Mamta Satoor <ms...@gmail.com>.
Dyre, before I can understand the entire email, I need understanding this
part of your mail
"Assume I have a table T and a view V that references it, and that I
currently have select privilege on T." Who owns the table T when you say I
have a table T? Also, let me take the case where you are not the owner of
table T and you have been granted select privilege on T, then you don't
automatically get select privilege on view V. In that case, this statement
doesn't sound right "I currently have select privilege on T. Assume that I
have created a prepared statement P that selects from V." If you have select
privileges on T only, then you should not be able to preapre a statement
which selects from V. So, it will be good to know the exact ownership of the
objects and the exact privileges granted to the user who is trying to
prepare a statement.
thanks,
Mamta
On 4/23/07, Dyre.Tjeldvoll@sun.com <Dy...@sun.com> wrote:
>
> Mamta Satoor <ms...@gmail.com> writes:
>
> > Dyre, my memory has gone rusty on this topic but what I seem to
> recollect is
> > not everything dependent on table will also be dependent for
> TablePermsDescr
> > too. This is because say the table owner creates a view on that table,
> then
> > no TablePermsDescr is required by such a view but that view will depend
> on
> > the TableDescriptor.
>
> Not sure I understand this. Assume I have a table T and a view V that
> references it, and that I currently have select privilege on T. Assume
> that I have created a prepared statement P that selects from V.
> If someone revokes my select privilege on T, I should no longer be
> allowed execute P should, I?
>
> P should become invalid as a consequence of the revoke, right?
>
> When I run the test in question (lang/grantRevokeDDL2.sql) I observe
> that the revoke results in
> DependencyManager.invalidateFor() being called on
> TablePermsDescr (as Provider), and that the TablePermsDescr's dependency
> list is empty.
>
> The TableDescr, on the other hand, appears to list the statements
> referring to that table as its dependents. So if there had been a
> dependency chain like so:
>
> TablePermsDescr -> TableDescr -> Statement
>
> a revoke would have triggered a statement re-compile.
>
> But TableDescr doesn't implement the Dependent interface, only the
> Provider interface (it doesn't implement makeInvalid()), and the
> TableDescr isn't really invalidated by the revoke, only the statement
> is. So perhaps the TablePermsDescr should have a direct dependency to
> the statement? If so; when should that dependency be established? The
> dependency between TableDescr and Statement happens during
> compilation, but the TablePermsDescr is created during execution. Can
> we just copy the dependents from TableDerscr to
> TablePermsDescr? Say, in TablePermsDescr's constructor?
>
> --
> dt
>
>
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Mamta Satoor <ms...@gmail.com> writes:
> Dyre, my memory has gone rusty on this topic but what I seem to recollect is
> not everything dependent on table will also be dependent for TablePermsDescr
> too. This is because say the table owner creates a view on that table, then
> no TablePermsDescr is required by such a view but that view will depend on
> the TableDescriptor.
Not sure I understand this. Assume I have a table T and a view V that
references it, and that I currently have select privilege on T. Assume
that I have created a prepared statement P that selects from V.
If someone revokes my select privilege on T, I should no longer be
allowed execute P should, I?
P should become invalid as a consequence of the revoke, right?
When I run the test in question (lang/grantRevokeDDL2.sql) I observe
that the revoke results in
DependencyManager.invalidateFor() being called on
TablePermsDescr (as Provider), and that the TablePermsDescr's dependency
list is empty.
The TableDescr, on the other hand, appears to list the statements
referring to that table as its dependents. So if there had been a
dependency chain like so:
TablePermsDescr -> TableDescr -> Statement
a revoke would have triggered a statement re-compile.
But TableDescr doesn't implement the Dependent interface, only the
Provider interface (it doesn't implement makeInvalid()), and the
TableDescr isn't really invalidated by the revoke, only the statement
is. So perhaps the TablePermsDescr should have a direct dependency to
the statement? If so; when should that dependency be established? The
dependency between TableDescr and Statement happens during
compilation, but the TablePermsDescr is created during execution. Can
we just copy the dependents from TableDerscr to
TablePermsDescr? Say, in TablePermsDescr's constructor?
--
dt
Re: Question about grant/revoke
Posted by Mamta Satoor <ms...@gmail.com>.
Dyre, my memory has gone rusty on this topic but what I seem to recollect is
not everything dependent on table will also be dependent for TablePermsDescr
too. This is because say the table owner creates a view on that table, then
no TablePermsDescr is required by such a view but that view will depend on
the TableDescriptor.
Mamta
On 4/16/07, Dyre.Tjeldvoll@sun.com <Dy...@sun.com> wrote:
>
> Mamta Satoor <ms...@gmail.com> writes:
>
> > When a revoke is issued, Derby sends an
> > DependencyManager.REVOKE_PRIVILEGEinvalidation to dependents of the
> > privilege being revoked.
>
> Hmm, I've added some trace, and as far as I can tell, the only
> Provider that gets DependencyManager.REVOKE_PRIVILEGE is
> TablePermsDescr. That is, TablePermsDescr is the only Provider for
> which DependecyManager.invalidateFor() gets called with
> action=REVOKE_PRIVILEGE, after issuing a revoke. But in this case the
> TablePermsDescr doesn't have any dependents so no invalidation of
> prepared statements is done.
>
> How does one determine the what the dependents of TablePermsDescr
> should be?
> I would have thought that any dependent of the table itself would be a
> dependent of TablePermsDescr as well, but that doesn't seem to be the
> case... why?
>
> --
> dt
>
>
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Mamta Satoor <ms...@gmail.com> writes:
> When a revoke is issued, Derby sends an
> DependencyManager.REVOKE_PRIVILEGEinvalidation to dependents of the
> privilege being revoked.
Hmm, I've added some trace, and as far as I can tell, the only
Provider that gets DependencyManager.REVOKE_PRIVILEGE is
TablePermsDescr. That is, TablePermsDescr is the only Provider for
which DependecyManager.invalidateFor() gets called with
action=REVOKE_PRIVILEGE, after issuing a revoke. But in this case the
TablePermsDescr doesn't have any dependents so no invalidation of
prepared statements is done.
How does one determine the what the dependents of TablePermsDescr
should be?
I would have thought that any dependent of the table itself would be a
dependent of TablePermsDescr as well, but that doesn't seem to be the
case... why?
--
dt
Re: Question about grant/revoke
Posted by Mamta Satoor <ms...@gmail.com>.
When a revoke is issued, Derby sends an
DependencyManager.REVOKE_PRIVILEGEinvalidation to dependents of the
privilege being revoked. Bryan's
suggestion is a sure shot to not miss any statments but like he pointed out,
that will end up invalidating statements that are not affected by the revoke
privilege.
Mamta
On 4/3/07, Dyre.Tjeldvoll@sun.com <Dy...@sun.com> wrote:
>
> Daniel John Debrunner <dj...@apache.org> writes:
>
> > Dyre.Tjeldvoll@Sun.COM wrote:
> >> While working on re-using resultsets (DERBY-827) I've discovered that
> >> calls to
> >> getLanguageConnectionContext().getAuthorizer().authorize(this , 1);
> >> have been added in places that I don't think are compatible with
> >> re-using result sets.
> >
> > I think that the checking authorization once is the desired behaviour,
> > not every execution, for performance reasons. The statements should be
> > invalidated when a revoke is executed.
>
> Sigh... I was so happy because I figured out how to move the
> checking into execute(), AND the test passed on the first attempt! Oh
> well, that's life :) What you say about performance makes sense. So do
> the grant/revoke expert(s) have an opinion about how to invalidate all
> statements affected by a revoke (or grant)?
>
> --
> dt
>
>
Re: Question about grant/revoke
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> I would not recommend a blanket
> approach when the mechanism to depend on specific objects already exists.
+1
I have no idea what I was thinking about :) It is certainly better
to track the dependencies properly.
thanks,
bryan
Re: Question about grant/revoke
Posted by Daniel John Debrunner <dj...@apache.org>.
Bryan Pendleton wrote:
>> have an opinion about how to invalidate all
>> statements affected by a revoke (or grant)?
>
> A crude technique would be to simply invalidate *all*
> statements whenever a revoke or grant is executed.
I thought statements were already invalidated on a revoke,
based upon the objects they depend on. I would not recommend a blanket
approach when the mechanism to depend on specific objects already exists.
Dan.
Re: Question about grant/revoke
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> have an opinion about how to invalidate all
> statements affected by a revoke (or grant)?
A crude technique would be to simply invalidate *all*
statements whenever a revoke or grant is executed.
The downside would be that some statements might
unnecessarily be invalidated.
The upside would be that it's simple and reliable.
thanks,
bryan
Re: Question about grant/revoke
Posted by Dy...@Sun.COM.
Daniel John Debrunner <dj...@apache.org> writes:
> Dyre.Tjeldvoll@Sun.COM wrote:
>> While working on re-using resultsets (DERBY-827) I've discovered that
>> calls to
>> getLanguageConnectionContext().getAuthorizer().authorize(this , 1);
>> have been added in places that I don't think are compatible with
>> re-using result sets.
>
> I think that the checking authorization once is the desired behaviour,
> not every execution, for performance reasons. The statements should be
> invalidated when a revoke is executed.
Sigh... I was so happy because I figured out how to move the
checking into execute(), AND the test passed on the first attempt! Oh
well, that's life :) What you say about performance makes sense. So do
the grant/revoke expert(s) have an opinion about how to invalidate all
statements affected by a revoke (or grant)?
--
dt
Re: Question about grant/revoke
Posted by Daniel John Debrunner <dj...@apache.org>.
Dyre.Tjeldvoll@Sun.COM wrote:
> While working on re-using resultsets (DERBY-827) I've discovered that
> calls to
>
> getLanguageConnectionContext().getAuthorizer().authorize(this , 1);
>
> have been added in places that I don't think are compatible with
> re-using result sets.
I think that the checking authorization once is the desired behaviour,
not every execution, for performance reasons. The statements should be
invalidated when a revoke is executed.
Dan.