db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "GrantRevokeImplementation" by DanDebrunner
Date Mon, 24 Jul 2006 22:38:14 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/GrantRevokeImplementation

------------------------------------------------------------------------------
  Operations:
   1. Determine if the set of granted permissions provides a complete intersect with the required
set.
  
+ Complicated by the fact that a permission required by be covered by one of several granted
permissions,
+ e.g. `{select C1 on T, fred}` is covered by any of:
+   * `{select C1 on T, <owner T>, fred}`
+   * `{select C1 on T, <owner T>, PUBLIC}`
+   * `{select * on T, <owner T>, fred}`
+   * `{select * on T, <owner T>, PUBLIC}`
+ assuming the current scheme where on the owner of an object can GRANT permissions on it.
+ 
  Objects:
   * Compile
     * `HashMap<rotuine UUID>` - For permission to execute routine (key UUID value constant
1)
@@ -62, +70 @@

  
  === Creation of object with privilege dependencies ===
  
+ Objects such as views, triggers and constraints have underlying actions that require that
the permissions be granted to the creator
+ at CREATE execution. E.g. with `CREATE VIEW V AS SELECT * FROM T` the creator of V must
have select permission on T.
+ If sometime later this select permission is revoked from the creator of V then V is dropped.
This linkage is implemented using
+ the dependency system, V depends on the privilege `{select T,owner of T,creator of V}`.
+ 
+ Objects:
+  * `List<<StatementPermission>` - The complete set of permissions needed to execute
the CREATE statement
+  * The list is walked to determine the sub-set of the permissions that the object will be
dependent on for REVOKE processing
+  * For each required `StatementPermission` a `PermissionsDescriptor` is created to be used
as Provider for the dependency system
+    * `StatementPermission {permission}`
+    * `Object owner {grantee}`
+    * `Existing granted privilege for permission {grantor}`
+  * Thus once the CREATE is executed the resultant object (e.g. !ViewDescriptor) will have
persistent dependencies to a collection of `PermissionsDescriptor` each identified by its
unique UUID corresponding to the row it represents.
+ 
+ Situation is complicated by the fact that if V depends on `{select T,owner of T,creator
of V}` a REVOKE of the form:
+  * `REVOKE SELECT ON T FROM <creator of V>
+ will drop V, but '''not''' if it was proceeded by a GRANT of the form:
+  * GRANT SELECT ON T TO PUBLIC
+ 
+ == Issues ==
+  1. Too many ways of representing permissions, !PrivilegeInfo, !StatementPermission, !PermissionDescriptor,
UUID. Possible solution:
+    * Use !StatementPermission everywhere
+    * Change/Merge !PrivilegeInfo into the grant revoke constant action, and have the data
pased into the constant action consist of a (or set of) !StatementPermission  object(s).
+    * Re-work/clarify !PermissionsDescriptor
+      * Ensure consistently it refers to a single row
+      * Remove it from being a public-api, only use within the !DataDictionaryImpl.
+ 
+  1. Permissions cache within !DataDictionaryImpl - Not sure how this ties into the scheme,
how does it support locking etc.
+  1. Is it clear as to which module has which responsibilities? Three possible models:
+     a. !DataDictionary is responsible for storage of rows representing granted permissions
only, no logic about what to do with those rows. That logic (such as searching for `PUBLIC`
&`fred` and the relationship between table & columns permissions) is handled by the
!StatementPermission objects
+     a. !DataDictionary is repsonsible for everything, has methods which are passed `StatementPermission`
and all logic below the covers. E.g. isGranted(StatementPermission), addGrantedPermission(StatementPermission,
String grantor, String grantee). Is this pushing too much in to the data dictonary, whose
role is really just storing SQL catalog objects.
+     a. Logic on how to handle permissions is spread across the data dictionary and other
code (e.g. !CompilerContextImpl). This seems to be where to code is today.
+ 

Mime
View raw message