db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Issue with using dependency manager for table level permission tracking
Date Fri, 21 Jul 2006 18:34:08 GMT
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 <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.
> >
> >
> >
>
>

Mime
View raw message