[ http://issues.apache.org/jira/browse/DERBY-1330?page=all ]
Mamta A. Satoor updated DERBY-1330:
-----------------------------------
Attachment: Derby1330uuidIndexForPermsSystemTablesV4diff.txt
Derby1330uuidIndexForPermsSystemTablesV4stat.txt
The patch Derby1330PrivilegeCollectionV3diff.txt attached to this JIRA entry
was recently committed into main trunk. I am working on revoke privilege which
is based on that committed patch. While working on revoke privilege, I realized
that I have incorrect logic for getting a permission descriptor from system
tables based on the unique uuid. SYSTABLEPERMS, SYSCOLPERMS and SYSROUTINEPERMS
each have a uuid column called TABLEPERMSID, COLPERMSID and ROUTINEPERMSID
respectively. When a view\constraint\trigger is found to be dependent on a
permission, we have the dependency manager track view\constraint\trigger's
dependency on that permission's unique uuid. Later on, that unique uuid can be
used to get the unique row from the system tables. The patch
Derby1330PrivilegeCollectionV3diff.txt accidentally looked for combination of
unique uuid and
permission type to find the exact unique row from the system tables. The uuid
column is sufficient to find the unique row form these 3 system tables and
there is no need to keep track of permission type.
I have attached a patch (Derby1330uuidIndexForPermsSystemTablesV4diff.txt) to
fix that behavior. The patch gets rid of requirement of permission type along
with the uuid to find a unique row. Fixing this has in fact cleaned up the
supporting code quite a bit. For instance, there is no need for special class
DDColumnPermissionDependableFinder or no need for a constructor in
ColPermsDescriptor which takes permission types in the form of an int.
DDdependableFinder is much cleaner too with this patch. In addition, I have
also created a unique index on the uuid for these 3 system tables in order to
quickly locate a row in those system tables.
svn stat -q output is attached as
Derby1330uuidIndexForPermsSystemTablesV4stat.txt
Can someone please review this patch for me and submit it to the trunk if
everything looks good?
The grantRevokeDDL.sql test is ran fine and I have fired derbyall.
> 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
> Assignee: Mamta A. Satoor
> Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html,
> AuthorizationModelForDerbySQLStandardAuthorizationV2.html,
> Derby1330PrivilegeCollectionV2diff.txt,
> Derby1330PrivilegeCollectionV2stat.txt,
> Derby1330PrivilegeCollectionV3diff.txt,
> Derby1330PrivilegeCollectionV3stat.txt,
> Derby1330ViewPrivilegeCollectionV1diff.txt,
> Derby1330ViewPrivilegeCollectionV1stat.txt,
> Derby1330uuidIndexForPermsSystemTablesV4diff.txt,
> Derby1330uuidIndexForPermsSystemTablesV4stat.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
