[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12425933 ] Mamta A. Satoor commented on DERBY-1330: ----------------------------------------
Basically, during an object create time, Derby will first look for the required privilege at the user level. If found, then the object will depend on that user-level privilege, for it's entire life. If privilege is not found at user-level, then Derby will look for that privilege at PUBLIC level. If found, then the object will depend on that PUBLIC level privilege, for it's entire life. After the object creation, if the privilege on which it depends is revoked, the object will simply drop itself. Derby will not try to see if it can find any other privilege to replace the one being dropped so the object does not have to drop itself. Ideally, during the privilege revoke time, the dependent object should see if there is any other privilege that they can start relying on so that they don't have to drop themselves. eg user1 create t1 grant select on t1 to user2 grant select on t1 to public user2 create view v1 as select * from user1.t1 -- this view will depend on user-level select privilege on user1.t1 user1 revoke select on t1 from users -- the above revoke will drop user2.v1, Ideally, rather than dropping user2.v1, Derby can make user2.v1 depend on available PUBLIC level privilege -- this doesn't happen at this point and hence we should document the existing behavior to clear any confusion another eg user1 create t1 grant select on t1 to PUBLIC user2 create view v1 as select * from user1.t1 -- this view will depend on PUBLIC-level select privilege on user1.t1 since no user level privilege is around user1 grant select on t1 to public revoke select on t1 from PUBLIC -- the above revoke will drop user2.v1, Ideally, rather than dropping user2.v1, Derby can make user2.v1 depend on available user-level privilege -- this doesn't happen at this point and hence we should document the existing behavior to clear any confusion > 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.0.0 > Reporter: Mamta A. Satoor > Assigned To: Mamta A. Satoor > 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
