[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12430438 ] Yip Ng commented on DERBY-1330: -------------------------------
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? For example, in the case of TablePermsDescriptor, there is one key that is composed of (grantee + tableUUID) and the other is the UUID of the TablePermsDescriptor. However, in its equals() and hashCode() implementation, it only takes in account for the (grantee + tableUUID) case. The getTablePermissions( UUID ) and other getXXXPermissions(UUID) seems to be mainly used by the dependency manager when it needs to load the stored dependencies which have PermissionDescriptor as a provider id but currently there is no code to force loading these stored dependencies. So in order to reproduce the NPE problem, one can call getPersistentProviderInfos(Dependent) of the dependency manager. > 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
