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 Fri, 25 Aug 2006 16:12:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12430533 ] 
            
Mamta A. Satoor commented on DERBY-1330:
----------------------------------------

Yip, the NPE behavrior you are describing is something I had run into before the dependency
manager (DM) was changed by Dan with Revision: 425479 DERBY-1581. (You can find the disucssion
of this very topic in DERBY-1539). 

Prior to Dan's changes, DM loaded the passed Provider while building the list of dependents
for the passed Provider. But since the Provider object is already available to DM as parameter
to the method, there really is not need to recreate Provider object. Before Dan's changes
to not construct Provider object, the code path used to run into hashCode() and would get
null pointer exception because at this point in DM, we only know about the UUID and not the
tableUUID. 

After Dan's fix for the Provider objects, we do not go through the cache to construct the
Provider object anymore and hence do not run into the hashCode() which expects that tableUUID
be non-null. 

Hope this answers your question.

> 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

       

Mime
View raw message