1.1 Name: Permissions Explained
1.2 Author: Brian Jones brianj@otterspace.com
1.3 Purpose: describe the concept of permissions in detail.
1.4 Creation: April 24, 2004
1.5 CVS $Id: permissions_explained.html,v 1.1 2004/06/24 21:22:47 brianj Exp $
1.6 Change history
1.1 series of email messages between almost the entire project team over days
1.2 See the Core Concepts document for definition of terms used.
1.3 Logs from many discussions with Romaq, Jon Smith, Rosella and myself
Central to the security and internal consistency of the NMC2 model is the idea that we can grant very fine-grained permission to people or groups.
The mechanism for doing this is collectively referred to as the "permission model." It includes individual permissions, the means to group permissions into policies, and the means to assign permissions to grant accounts and objects the rights to carry out operations.
Being fine grained means that we can grant very precise permissions to very specific cases. For instance, a coarse grained permission might be "access the file system." A fine grained permission might be "Jim can read files in /tmp and any of its subdirectories but not create, edit, or delete them."
The challenge of establishing the permission model then is in the following areas:
Having dozens, hundreds, or even thousands of permissions, applied to thousands or millions of objects and resources is a daunting task. That's why permissions systems include the notion of policies.
A policy is a way to group one or more permissions together, possibly using some form of wildcard or explicit list of objects and resources and the list of actions they allow or deny. Then, one can assign policies to players, to characters, to objects (the subjects) as desired.
It would be reasonable that some accounts would have multiple policies in force at a time. In this model, we use the idea of the "policy stack" on the subject. A policy stack has the policies applied in an order, the most recently applied policy being uppermost on the stack.
When a request to carry out an operation requires a permission check, the policy stack is searched from "the top down" so the newest policy granted is checked first.
When searching for permission, the general rule called "reject domination" applies: if it any point in the permission checking process a permission is reached that rejects this subject then the permission checking process finishes immediately and the subject is denied the right to carry out the operation.
The reject operation thus dominates any grants.
Thus, to disable an account, for instance, one need only push a "reject all actions on all objects" policy object onto the account's permission stack, and any attempt to carry out any operation with any permission checking will fail immediately on that account. Amusingly, if a player did this to themselves, they would then be unable to undo it, because they wouldn't pass the permission check to pop the permission entry off the stack that rejects them.
Thus, the rule of "reject domination" must be considered when setting policies.
A permission check always result in approve or reject. But there is a third case, which is a person not having any permission entry on something at all. With no explicit "grant" in the chain of permissions, a reject is returned. This is another consequence of reject domination.
The administrator (the person who controls the computer/account that hosts the game software) is the one who has the ultimate control of all permission policies, because this person creates the Master Security Policy.
This is a policy described outside of the database of the game and which is considered "at the bottom" of every security stack. Any rejects added to this policy would be forbidden to any subject in the game in every case. This is the most dominant policy in the system.
This policy is free to include grants as well as rejects! If the MU was very liberal (such as Nameless) it might grant all accounts the right to create objects. Without such a grant, no account could create objects in the MU until they were assigned an in-game policy that gave them the grant.
Notice that the lack of including a grant doesn't prohibit a grant being added in-game. But the act of including a reject forever blocks any grants given in the game from working.
Even here, the reject domination rule is in effect.
The Master Security Policy should be carefully considered before being established. Rejects here are forever. Grants here are not.
Having an empty Master Security Policy would leave the system in a state where no player had the right to create a security policy in the game, which would be disastrous!
In NMC1 (and all FB/Tiny variations with locks) there are a few ways of interpreting locks:
In this security model, there are only two choices:
Not giving a permission in this model will cause failure.
There are good reasons that one would probably setup the Master Security Policy to grant all permissions to one or more accounts, and to reject anything that the site admin flatly refuses, such as file access permissions or outbound socket opening permissions.
There's very good reasons to grant all ownership VR permissions to every account by default. This would allow every account to create, edit, read, and destroy all objects in VR space they own. The permission model should be strong enough that ownership is dominated by the reject domination rule: a "reject" permission added to the stack of someone could block their ownership privileges!
Thus, by reject domination, it's often easier to be more liberal on top for VR based things, and very conservative on top with system risks. And to NOT assign reject rules at the top that you can live with forever, because a reject rule trumps later grants.