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 20:53:16 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:

  Notes taken during understanding the GRANT/REVOKE implementation as part of understanding
the changes for DERBY-1539
+ == Terminology ==
+ Some general terminology that is used by the code:
- Compile Time - GRANT statement
+  * `permission` - Some permission required to perform an action (e.g. execute on a function)
+  * `user` - The user executing an action
+  * `grantee` - A user who has been granted a permission to perform an action
+  * `grantor` - A user who has granted a permission to a grantee
+  * `privilege` - A triplet of {permission,grantor,grantee} that generated by a GRANT statement
and stored in  a system table.
+ == Statements ==
+ === GRANT statement ===
- GRANT privilege described by
-    PrivilegeInfo + extra info
-      RoutinePrivilegeInfo + List(grantees)
-    GRANT statement 1-1 Routine 1-1 RoutinePrivilegeInfo 1-N Grantee
+ Input - '''`{permision*,grantor,grantee*}`''' - Grants permission on one or more actions
to one or more grantess by a single grantor.
+ Operations
+  1. Store input in system tables
+ Objects representing `{permision,grantor,grantee*}`
+  * `PrivilegeInfo {permission*}` - Created as compile time and used like constant action
+  * `List<grantee>` - Created at compile time
+  * current user `{grantor}` - used at execution time
+  * `PermissionsDescriptor {permission*,grantor,grantee}` - Created at execution time and
passed into DataDictionary for storage.
+ Issues
+  * `PermissionsDescriptor` object passed in is reset each time with a different grantee
- does this match the intended purpose of such descriptors which are `TupleDescriptors` and
match a single row in the database?
+  * `PrivilegeInfo` looks very much like a constant action, the constant action for grant/revoke
is more or less just an empty object that calls the execute method on `PrivilegeInfo`. Should
this code be re-factored to have all the logic in a constant action, to match the pattern
of other DDL statements.
+ === REVOKE statement ===
+ Input - `{permision,grantor,grantee*}`  - Revoke of permissions to one or more grantees
on a single permission by a single grantor
+ Operations
+  1. Notify dependents of removal of permission
+  1. Remove input from system tables
+ === Arbitrary Statement Execution ===
+ Input `{permission*,user}` - Set of permissions required by user for execution.
- Runtime of GRANT statement
-     RoutinePrivilegeInfo stored in constant action plus list of names
+ Operations:
+  1. Determine if the set of granted permissions provides a complete intersect with the required
- Arbitary Statement S1 - 1-N StatementPermissions
+ Objects:
+  * Compile
+    * `HashMap<rotuine UUID>` - For permission to execute routine (key UUID value constant
+    * `HashMap<StatementSchemaPermission>` - For permission to create/modify schema
(key object, value same as key)
+    * `HashMap<StatementTablePermission>` - Table level permissions (key object, value
same as key)
+    * `HashMap<StatementTablePermission>` - Column level permissions (key object, value
+    * Permissions represented by the four !HashMaps are converted into a `List<StatementPermission>`
for execution.
+  * Execution
+   * `List<StatementPermission>` - The set of permissions needed to execute all the
actions for this statement
+   * `StatementPermission {permission*}` - Created at compile time
- StatementPermissions describe the type of permission required, not an instance of a grant.
- E.g. EXECUTE on routine A
- Execution of statement goes through set of StatementPermissions and sees if the
- permissions have been granted for the current user.
+ Issues
+  * Why !HashMaps in the three cases a !HashSet would do?
+  * Why use a UUID for routine and not a `StatementPermission`?
+  * Why the Iterator based code to convert to a List, aren't there methods to add the contents
of one collection to another?
+ === Creation of object with privilege dependencies ===
-  StatementPermission + user -> check against set of existing granted privileges
-     implemented by check method on StatementPermission 
- Dependency system for automatic drop (e.g drop view when select priv is dropped).
- The CREATE statement for objects that can be dropped on a revoke automatically
- contain the list of require permission
- Code walks this list to determine the sub-set of permissions that are required
- for the object to be dependent on. Sub-set because:
-      - multiple objects created in a single statement (constraints in CREATE TABLE)
-      - no dependencies for owner of object
-      - ???
- Since the dependency system for persistent dependies needs a persistent object
- the dependency is made on a PrivilegeDescriptor. When an object needs this
- dependency it calls the  StatementPermission  to get a specific PermissionDescriptor
- for the required user (the one creating the object).
- Then this PermissionDescriptor is added to the set of dependencies for the object.
- thus really PermissionDescriptor = StatementPermission + other stuff

View raw message