db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yip Ng (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
Date Fri, 25 Aug 2006 17:21:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12430545 ] 
            
Yip Ng commented on DERBY-1330:
-------------------------------

Mamta, thanks for those jira links.  My actual concern is the working of the permission cache.
 From what I interpret from those discussion, it seems that getXXXPermissions(UUID) are currently
never called from the code line; thus, they are never exercised.   Dan's patch addressed the
issue of avoiding to reconstruct the "provider" from the stored dependencies; however, my
example above is actually of the "dependent".  There are cases where we need to exercise getXXXPermissions(UUID)
to make use of the stored dependencies.  For example, when granting a view that has underlying
objects that is not own by the grantor, we need to go through all the view's providers to
see if they are own by the grantor  ( + grant option check, but since Derby does not support
this yet, I'll skip the details).  So, the getXXXPermission(UUID) needs to be called and currently
the equals and hashCode methods of the various PermissionDescriptor types do need to address
the nullibility of grantee and tableUUID or other related field that is used for the hashing.
 Even though the nullibility are addressed... back to my original question:

How does the PermissionsCache work with respect to passing two type of keys to represent the
same PermissionDescriptor? If an object can be represented by two type of keys, how does it
take advantage of the cache? Once one key's identity is set, its hash code should remain the
same while it is stored in the cache, wouldn't the "other" key always miss then?


> Provide runtime privilege checking for grant/revoke functionality
> -----------------------------------------------------------------
>
>                 Key: DERBY-1330
>                 URL: http://issues.apache.org/jira/browse/DERBY-1330
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.2.1.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>             Fix For: 10.2.1.0
>
>         Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html,
DERBY1330javaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, Derby1330MinorCleanupV7diff.txt,
Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt,
Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setUUIDinDataDictionaryV10diff.txt,
Derby1330setUUIDinDataDictionaryV10stat.txt, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDictionaryV8stat.txt,
Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt,
Derby1330uuidIndexForPermsSystemTablesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt,
Derby1330uuidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTablesV6stat.txt,
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

       

Mime
View raw message