db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
Date Mon, 10 Jul 2006 17:40:31 GMT
    [ 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


Mime
View raw message