[ 
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

Reply via email to