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 21:37:42 GMT
BTW, I think the issue is really with just triggers.

Views can only depend on select privileges, since we don't allow DML through
views. So, when a ViewDescriptor gets an action anything other than
REVOKE_SELECT_PRIVILEGE from dependency manager,  it can simply ignore them.
And for a REVOKE_SELECT_PRIVILEGE, the view can drop itself.

A constraint can only need REFERENCES privilege and hence ignore anything
other than REVOKE_REFERENCES_PRIVILEGE. On a REVOKE_REFERENCES_PRIVILEGE,
the constraint can drop itself.

It's just the triggers that can depend on many different types
of privileges and hence triggers will need to be able to distinguish between
various action types.

thanks,
Mamta


On 7/21/06, Mamta Satoor <msatoor@gmail.com> wrote:
>
>  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