[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420121 ]
Mamta A. Satoor commented on DERBY-1330: ---------------------------------------- Knut, the diffs you are noticing is in one of the new tests that I added to grantRevokeDDL.sql The diff is for following sql which is executed by mamta3(Note that mamta3 does not have SELECT privilege on mamta2.v22.c111 and on mamta2.v21.c111 but does have SELECT privilege on mamta1.t11) create view v33 as select v22.c111 as a, t11.c111 as b from mamta2.v22 v22, mamta1.t11 t11, mamta2.v21; When this create view is compiled by Derby, it collects the privileges required by the create view. Derby collects following privilege requirements for the create view sql above 1)SELECT on mamta2.v22 2)SELECT on mamta1.t11 3)SELECT on mamta2.v21 4)ownership of the schema in which create view is being issued Later on, at create view execution time, Derby grows through the required privileges list and checks if mamta3 has the required privileges or not. And since mamta3 does not have the required privileges on mamta2.v22 and mamta2.v21, the create view fails. In the diff that you posted above, both the error messages are correct. It seems like 1)either the order in which the privilege requirements get added to the list in compile phase is not always the same 2)or the order in which privileges get retrieved in the execution phase is not always the same and hence different error messages CompilerContextimpl.addRequiredTablePriv() has following requiredTablePrivileges.put(key, key); and requiredTablePrivileges is defined as follows in CompilerContextimpl private HashMap requiredTablePrivileges; Is this a Java behavior that you can count on the order in which items will be added and retrieved from HashMap? At this point, I am not sure, how to make sure that items get added and retrieved in the same order from the HashMap so that we will have consistent error message return from the create view sql above. Any insight from the list will be appreciated. > 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 > > 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