|
Relational NT
A relational database kernel shaped around NT-style object management.
|
Public Member Functions | |
| std::set< AUTH_CLAIM > | Firewall (AUTH_METHOD method) |
| Validates a connection during login. | |
| const bool | Access (const ObjectManager::registry *object, const void *connection_context) |
| Validates permission to an object. | |
| const bool nt::PermissionsManager::Access | ( | const ObjectManager::registry * | object, |
| const void * | connection_context ) |
Validates permission to an object.
Checks the security descriptor on the head of the object found in ObjectManager::registry. It should also check connection metadata that is still to be defined, such as user group and policy.
It is still undecided whether this should run on every attempt to get hold of an object, since that might produce significant overhead.
Note that the permissions systems also rely on objects with capabilities, so imagining the case an ephemeral relation is created based on 3 other stored relations, while you can access the ephemeral relation, you cannot directly access the other 3 relations. You need explicit permission to create a handle on the others.
Here's an example tree: /system /multigroups /coffee_shop /relations /user {type : stored} /order {type : stored} /user_and_order {type : ephemeral; deps = [/system/multigroups/coffee_shop/relations/users, /system/multigroups/coffee_shop/relations/orders]} /users /peter /permissions /multigroups/coffee_shop/relations/user_and_order {descriptor : [read]} /paul /permissions /multigroups/coffee_shop/relations/user {descriptor : [write, read]}
Meaning that peter has access to read the user_and_order ephemeral relation, but cannot open a handle on user and order.
| object | Object being accessed. |
| connection_context | Connection metadata for the caller. |
| std::set< AUTH_CLAIM > nt::PermissionsManager::Firewall | ( | AUTH_METHOD | method | ) |
Validates a connection during login.
| method | Authentication method used by the connection. |