Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 49341 invoked from network); 24 Apr 2007 17:44:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Apr 2007 17:44:45 -0000 Received: (qmail 56255 invoked by uid 500); 24 Apr 2007 17:44:50 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 56214 invoked by uid 500); 24 Apr 2007 17:44:50 -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 56193 invoked by uid 99); 24 Apr 2007 17:44:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2007 10:44:50 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of msatoor@gmail.com designates 66.249.82.229 as permitted sender) Received: from [66.249.82.229] (HELO wx-out-0506.google.com) (66.249.82.229) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2007 10:44:42 -0700 Received: by wx-out-0506.google.com with SMTP id s18so2221164wxc for ; Tue, 24 Apr 2007 10:44:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZBKmY01gwBKdN7ZTZ1nxTJ8gVyx47sdfjBHZ7HbxwkF5CH0j6MesxToaIk/1GG5mxTY42kD0vM0gvQHIRxz+G3lhNLrTfQ4mdRO7oxcJiD3M0nf/nQ+ZQdlE8gCM+wZs6CD56I+tzDH4itiga0TKcMTtJ07zeEr7SmEwPFckhf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=meYyNDepXffs4cRPJlh3NcsnaCRNsGhbHrSUncuvjG/Ydf2qp6HippPVKExitKgFza0rf19gpuHeVCM2rD99vHmsQMlZgyyRLpZhh/Uf5SA0vPSiySEqtC4Zk+YMBP+pHibIAdUL5/A5ZNCzExDn6ArgYyo73Id3uRgkAa/UMfY= Received: by 10.90.32.14 with SMTP id f14mr2367636agf.1177436661823; Tue, 24 Apr 2007 10:44:21 -0700 (PDT) Received: by 10.100.189.9 with HTTP; Tue, 24 Apr 2007 10:44:21 -0700 (PDT) Message-ID: Date: Tue, 24 Apr 2007 10:44:21 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: Question about grant/revoke In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_275521_15549307.1177436661713" References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_275521_15549307.1177436661713 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 wrote: > > Mamta Satoor 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 > > ------=_Part_275521_15549307.1177436661713 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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 < Dyre.Tjeldvoll@sun.com> wrote:
Mamta Satoor < msatoor@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


------=_Part_275521_15549307.1177436661713--