db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
Date Tue, 11 Jul 2006 06:36:31 GMT
     [ 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


Mime
View raw message