[
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
