Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 77192 invoked from network); 21 Jul 2006 18:34:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Jul 2006 18:34:32 -0000 Received: (qmail 28215 invoked by uid 500); 21 Jul 2006 18:34:30 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 28175 invoked by uid 500); 21 Jul 2006 18:34:30 -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 28137 invoked by uid 99); 21 Jul 2006 18:34:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Jul 2006 11:34:30 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of msatoor@gmail.com designates 66.249.82.192 as permitted sender) Received: from [66.249.82.192] (HELO wx-out-0102.google.com) (66.249.82.192) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Jul 2006 11:34:29 -0700 Received: by wx-out-0102.google.com with SMTP id t15so465904wxc for ; Fri, 21 Jul 2006 11:34:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i0rDWTJLDogDjrvRiGoDRcSJq4a9mlHVBigXLYnxHkEIhHFek2bMdyDvisKZbQoRtuo3AELcIAE90RvYcmh7DlivGojEWR64GuFJDNRnLRLU+2CYfjTB7fuwDdNMglYuQZ8YZOTRO+2t9W4JBWsKekoY6yj6WkTWJmt674OccMc= Received: by 10.70.68.10 with SMTP id q10mr1574137wxa; Fri, 21 Jul 2006 11:34:08 -0700 (PDT) Received: by 10.70.47.8 with HTTP; Fri, 21 Jul 2006 11:34:08 -0700 (PDT) Message-ID: Date: Fri, 21 Jul 2006 11:34:08 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: Issue with using dependency manager for table level permission tracking In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18785_27957911.1153506848278" References: <44B2F183.4060704@apache.org> <44B2FCC8.3010408@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_18785_27957911.1153506848278 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, After working on much of the ground work for revoke, I have finally come to implement the revoke privilege such that only the objects that depend on the specific permission type being revoked should drop themselves. I thought I could do that by having dependency manager send specific action types depending on the kind of the privilege that is getting revoked. I wrote some prototype code so that during the execution of revoke statement, I send specific action types like REVOKE_SELECT_PRIVILEGE / REVOKE_UPDATE_PRIVILEGE / REVOKE_REFERENCES_PRIVILEGE etc using the dependency manager to all the dependents of a Table/Column Permission Descriptor. But I am unfortunately finding out that the specific action types are not helpful to the dependents because by now the dependents have lost the information about what kind of privilege requirement they need. I want to provide an example at this point user1 connects creates table t1 grants select on t1 to user2 -- this add a new row in SYSTABLEPERMS for t1 and user2 with select privilege on grants insert on t1 to user2 -- modifies the existing row in SYSTABLEPERMS for t1 and user2 and makes inserts privilege flag on user2 connects -- following view v1 really needs only select permission on user1.t1and should not have any dependency on insert permission. But all we tell the dependency manager is to add view v1's dependency on the row in the SYSTABLEPERMS for t1 and user2. But we don't say exactly what kind of privilege view v1 depends on(I don't know if more specifics can be given to the dependency manager based on it's current design) create view v1 as select * from user1.t1; user1 connects back -- Now, for following revoke, the dependency manager will send the action REVOKE_INSERT_PRIVILEGE and ViewDescriptor for v1 will get that action. But ViewDescriptor has no idea what kind of privilege type it depends on and hence it can't take any specific action for the passed action. It will end up dropping itself because as per the spec, an object should drop itself if a required privilege is revoked from it. With the lack of information, ViewDescriptor assumes that the privilege being revoked is one of the required privileges. revoke insert on t1 from user2 So, I am back to the problem I had about a week or so back and leaning again towards changing the structure of SYSTABLEPERMS to match SYSCOLPERMS, so same row in SYSTABLEPERMS won't be shared for different privilege types for a given table and given grantee and grantor. I haven't yet looked at Satheesh's suggestion "Have you considered using PROVIDERFINDER that is part of dependency system? TableDescriptor, for example, stores column list that a view depends on using ColumnsInTable finder. A similar mechanism might work for TablePermDescriptor. " May be that will solve my problem. If anyone has any thoughts/ideas, please share them. Mamta On 7/10/06, Mamta Satoor wrote: > > After reading you mail, it seems like with revoke, I can send specific > action type to dependent objects ie say REVOKE_SELECT_PRIVILEGE / > REVOKE_UPDATE_PRIVILEGE / REVOKE_REFERENCES_PRIVILEGE etc rather than > generic REVOKE_PRIVILEGE and that way dependent objects can see if they > depend on that specific revoke privilege on the table. I think this > should provide me with enough information to decide if an object is really > impacted by a revoke or not. > > In order to implement the question you raised, I think I can fine tune the > action types even more ie rather than sending REVOKE_SELECT_PRIVILEGE for > say a REVOKE SELECT on table FROM ..., I can send > REVOKE_SELECT_PRIVILEGE_USER or REVOKE_SELECT_PRIVILEGE_PUBLIC and then the > dependent objects can see if they can find a privilege at PUBLIC level or > user level respectively and if yes, then start depending on the newly found > privilege. If not, then the object should drop itself. > > thanks for the pointer, > Mamta > > > On 7/10/06, Daniel John Debrunner wrote: > > > Mamta Satoor wrote: > > > > > That is on my todo list to figure out when I do the revoke privilege > > > implementation. But I am thinking that when a revoke privilege is > > > processed, > > > before dropping the dependent objects, a check will be made to see if > > some > > > other privilege can replace the privilege being revoked and if so, > > then > > > make > > > the objects depend on the newly found privilege. I have not spent > > enough > > > time yet to figure out exactly how I would code this. > > > > I think it's very much tied up with the question you are asking. > > > > One can use the dependency system as either: > > > > - Specific items (permissions) have been changed/dropped and the > > dependent (the view) needs to take specific action (e.g. check the > > select priv for public if select priv for user has been revoked) > > > > - Something the dependent (the view) depends on has changed and so the > > view needs to re-verify itself, which could be recompiling successfully, > > > > or being dropped. > > > > The dependency system will just perform a callback on the dependent with > > an action type, it's up to the dependent to decide what to do with that > > information. > > > > Dan. > > > > > > > > ------=_Part_18785_27957911.1153506848278 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
After working on much of the ground work for revoke, I have finally come to implement the revoke privilege such that only the objects that depend on the specific permission type being revoked should drop themselves.
 
I thought I could do that by having dependency manager send specific action types depending on the kind of the privilege that is getting revoked. I wrote some prototype code so that during the execution of revoke statement, I send specific action types like REVOKE_SELECT_PRIVILEGE / REVOKE_UPDATE_PRIVILEGE / REVOKE_REFERENCES_PRIVILEGE etc using the dependency manager to all the dependents of a Table/Column Permission Descriptor. But I am unfortunately finding out that the specific action types are not helpful to the dependents because by now the dependents have lost the information about what kind of privilege requirement they need.
 
I want to provide an example at this point
user1 connects
creates table t1
grants select on t1 to user2 -- this add a new row in SYSTABLEPERMS for t1 and user2 with select privilege on
grants insert on t1 to user2 -- modifies the existing row in SYSTABLEPERMS for t1 and user2 and makes inserts privilege flag on
user2 connects
-- following view v1 really needs only select permission on user1.t1 and should not have any dependency on insert permission. But all we tell the dependency manager is to add view v1's dependency on the row in the SYSTABLEPERMS for t1 and user2. But we don't say exactly what kind of privilege view v1 depends on(I don't know if more specifics can be given to the dependency manager based on it's current design)
create view v1 as select * from user1.t1; 
user1 connects back
-- Now, for following revoke, the dependency manager will send the action REVOKE_INSERT_PRIVILEGE and ViewDescriptor for v1 will get that action. But ViewDescriptor has no idea what kind of privilege type it depends on and hence it can't take any specific action for the passed action. It will end up dropping itself because as per the spec, an object should drop itself if a required privilege is revoked from it. With the lack of information, ViewDescriptor assumes that the privilege being revoked is one of the required privileges.
revoke insert on t1 from user2 
 
So, I am back to the problem I had about a week or so back and leaning again towards changing the structure of SYSTABLEPERMS to match SYSCOLPERMS, so same row in SYSTABLEPERMS won't be shared for different privilege types for a given table and given grantee and grantor.
 
I haven't yet looked at Satheesh's suggestion "Have you considered using PROVIDERFINDER that is part of dependency system? TableDescriptor, for example, stores column list that a view depends on using ColumnsInTable finder. A similar mechanism might work for TablePermDescriptor. " May be that will solve my problem.
 
If anyone has any thoughts/ideas, please share them. 
Mamta
 
On 7/10/06, Mamta Satoor <msatoor@gmail.com> wrote:
After reading you mail, it seems like with revoke, I can send specific action type to dependent objects ie say REVOKE_SELECT_PRIVILEGE / REVOKE_UPDATE_PRIVILEGE / REVOKE_REFERENCES_PRIVILEGE etc rather than generic REVOKE_PRIVILEGE and that way dependent objects can see if they depend on that specific revoke privilege on the table. I think this should provide me with enough information to decide if an object is really impacted by a revoke or not.
 
In order to implement the question you raised, I think I can fine tune the action types even more ie rather than sending REVOKE_SELECT_PRIVILEGE for say a REVOKE SELECT on table FROM ..., I can send REVOKE_SELECT_PRIVILEGE_USER or REVOKE_SELECT_PRIVILEGE_PUBLIC and then the dependent objects can see if they can find a privilege at PUBLIC level or user level respectively and if yes, then start depending on the newly found privilege. If not, then the object should drop itself.
 
thanks for the pointer,
Mamta

 
On 7/10/06, Daniel John Debrunner < djd@apache.org> wrote:
Mamta Satoor wrote:

> That is on my todo list to figure out when I do the revoke privilege
> implementation. But I am thinking that when a revoke privilege is
> processed,
> before dropping the dependent objects, a check will be made to see if some
> other privilege can replace the privilege being revoked and if so, then
> make
> the objects depend on the newly found privilege. I have not spent enough
> time yet to figure out exactly how I would code this.

I think it's very much tied up with the question you are asking.

One can use the dependency system as either:

- Specific items (permissions) have been changed/dropped and the
dependent (the view) needs to take specific action (e.g. check the
select priv for public if select priv for user has been revoked)

- Something the dependent (the view) depends on has changed and so the
view needs to re-verify itself, which could be recompiling successfully,
or being dropped.

The dependency system will just perform a callback on the dependent with
an action type, it's up to the dependent to decide what to do with that
information.

Dan.



 

------=_Part_18785_27957911.1153506848278--