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 Sat, 05 Aug 2006 05:29:14 GMT
    [ 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

       

Mime
View raw message