[ http://issues.apache.org/jira/browse/DERBY-1330?page=all ]
Mamta A. Satoor updated DERBY-1330:
-----------------------------------
Attachment: Derby1330ViewPrivilegeCollectionV1diff.txt
Derby1330ViewPrivilegeCollectionV1stat.txt
I have been working on storing privilege requirements for view (in Derby SQL
Authorization mode only) during create view time in SYSDEPENDS table. This
information in SYSDEPENDS will later be used at the revoke privilege time. That
patch for this work is attached as Derby1330ViewPrivilegeCollectionV1diff.txt
to this JIRA entry. All the views that depend on the privilege being revoked
will be dropped. The revoke privilege work to drop affected views is not
included in this patch.
The patch has 2 major components to it
1)If the query for create view is accessing view/s, then Derby engine flattens
all those view/s. Once the view flattening is finished, Derby engine goes
through all the columns for the flattened parent sql and it starts building the
privilege requirement for those columns. But since views are always accessed
with definer's privileges (which means that as long as a user has privilege to
access a view, the user can select from the view. This works even if the user
does not need direct privileges to the objects accessed by the view.), Derby
engine should not collect privilege requirements for objects accessed by views.
In order to implement this behavior, I have added a flag to QueryTreeNode which
will be set to false if the object is going to be accessed with definer's
privileges. During view flattening, the objects accessed by view will be marked
with definer privileges. Later, when the Derby enging goes through all the
columns, it will check if the column is marked with definer's privilege and if
so, then do not look for privilege requirement for that column.
2)Once the privileges have been collected for the create view in the bind
phase, they need to be recorded in SYSDEPENDS table during the execution phase
of the create view sql. SYSDEPENDS will add one row for every privilege
requirement for the view. The DEPENDENTID will be view descriptor and
PROVIDERID has to be a unique id to identify permission descriptor's uniquely.
In order to do this, PermissionsDescriptor needs to implement interface
Provider and it needs to have a UUID associated with it. This required addition
of a UUID column in SYSTABLEPERMS, SYSCOLPERMS and SYSROUTINEPERMS. This UUID
is required by the DependencyManager to uniquely identify a row for a given
PROVIDERID.
The patch mail to the derby developer list can be found at
http://www.nabble.com/-PATCH-DERBY-1330-Collect-privilege-requirements-for-views-tf1858264.html#a5075008.
This thread has more information about individual class changes.
> Provide runtime privilege checking for grant/revoke functionality
> -----------------------------------------------------------------
>
> Key: DERBY-1330
> URL: http://issues.apache.org/jira/browse/DERBY-1330
> Project: Derby
> Type: Sub-task
> Components: SQL
> Versions: 10.2.0.0
> Reporter: Mamta A. Satoor
> Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html,
> AuthorizationModelForDerbySQLStandardAuthorizationV2.html,
> Derby1330ViewPrivilegeCollectionV1diff.txt,
> Derby1330ViewPrivilegeCollectionV1stat.txt
>
> Additional work needs to be done for grant/revoke to make sure that only
> users with required privileges can access various database objects. In order
> to do that, first we need to collect the privilege requirements for various
> database objects and store them in SYS.SYSREQUIREDPERM. Once we have this
> information then when a user tries to access an object, the required
> SYS.SYSREQUIREDPERM privileges for the object will be checked against the
> user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and
> SYS.SYSROUTINEPERMS. The database object access will succeed only if the user
> has the necessary privileges.
> SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already
> populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't
> have any information in it at this point and hence no runtime privilege
> checking is getting done at this point.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
