I'm going to write a more detailed description of how inheritance works in InnerSpace later, but for now I'll use this page to keep some notes on properties and inheritance as compared to LambdaMOO.
The permissions on properties are drawn from this set: 'r' (read), 'w' (write), and 'c' (change ownership in descendants). Read permission lets non-owners get the value of the property and, of course, write permission lets them set that value. The 'c' permission bit is a little more complicated.
In InnerSpace, properties can have is_inherited() return true (which behind the scenes is the result of a 'inherited' ACL set on the property for the relevant user class.
Recall that every object has all of the properties that its parent does and perhaps some more. Ordinarily, when a child object inherits a property from its parent, the owner of the child becomes the owner of that property. This is because the 'c' permission bit is "on" by default. If the 'c' bit is not on, then the inherited property has the same owner in the child as it does in the parent.
The way we do it is that if the property is not found on the subject, we keep looking up the inheritance tree for a property of that name that has the 'inherited' ACL set.
As an example of where this can be useful, the LambdaCore database ensures that every player has a 'password' property containing the encrypted version of the player's connection password. For security reasons, we don't want other players to be able to see even the encrypted version of the password, so we turn off the 'r' permission bit. To ensure that the password is only set in a consistent way (i.e., to the encrypted version of a player's password), we don't want to let anyone but a wizard change the property. Thus, in the parent object for all players, we made a wizard the owner of the password property and set the permissions to the empty string, "". That is, non-owners cannot read or write the property and, because the 'c' bit is not set, the wizard who owns the property on the parent class also owns it on all of the descendants of that class.
In our case, the passwd is owned by the wizard (possibly by the wizard that created it, but since all wizards have the same ultimate level of access, it hardly matters). Since only the 'allow owners anything' and 'allow wizards anything' ACLs are set, this makes the passwd property inaccessible to any non-administrative users. The question, then, is how will the user change his own password? One solution is to write a verb that makes use of the sudo command to run some code with the permissions of the user who authored the verb. Another would be to simply add 'allow <user> anything'.
NOTE: It occurs to me that this last ACL may affect the inheritability of this object when it is attempted to be subclassed by a programmer allowed to do 'anything' with that item. When a property is sought on a particular item, its ancestors are searched in turn if the named item is not found on the item. If a property of that name is found, it's Entity.is_inherited() method is called to check if it has the 'inherited' bit set for the current user. By default, properties are readable to everybody, and owners and wizards have the special rule 'allow anything'.
Another, perhaps more down-to-earth example arose when a character named Ford started building objects he called "radios" and another character, yduJ, wanted to own one. Ford kindly made the generic radio object fertile, allowing yduJ to create a child object of it, her own radio. Radios had a property called 'channel' that identified something corresponding to the frequency to which the radio was tuned. Ford had written nice programs on radios (verbs, discussed below) for turning the channel selector on the front of the radio, which would make a corresponding change in the value of the 'channel' property. However, whenever anyone tried to turn the channel selector on yduJ's radio, they got a permissions error. The problem concerned the ownership of the 'channel' property.
As I explain later, programs run with the permissions of their author. So, in this case, Ford's nice verb for setting the channel ran with his permissions. But, since the 'channel' property in the generic radio had the 'c' permission bit set, the 'channel' property on yduJ's radio was owned by her. Ford didn't have permission to change it! The fix was simple. Ford changed the permissions on the 'channel' property of the generic radio to be just 'r', without the 'c' bit, and yduJ made a new radio. This time, when yduJ's radio inherited the 'channel' property, yduJ did not inherit ownership of it; Ford remained the owner. Now the radio worked properly, because Ford's verb had permission to change the channel.
The way things work in InnerSpace is that verbs run as the current user, not as the programmer. There is an exception to this, since programmers can use the sudo command to run a selected bit of code as themselves, but this wasn't meant to be used very often (it may also aggrevate the problem exposed by bug #16).
So the above scenario would play out like this:
- A user named Ford builds a radio. This fertile item has a property that is (by default) only editable by owners and wizards.
- A user named yduJ subclasses Ford's radio. She now has a fertile radio owned by *her*.
- The first time yduJ runs the 'change channel' verb, it runs with her permissions (because Ford didn't use sudo), and tries to set the 'channel' property (which has been marked as inheritable).
- The engine copies the property to yduJ's radio, changing the owner to yduJ.
- The engine attempts to modify the new 'channel' property on yduJ's radio. Since the ACL for the channel property is 'allow owners anything' by default, the change is sucessful.
The real question has to do with wizards, namely, is it a problem that all properties will appear inheritable to a wizard? This question probably needs to be considered in conjunction with thoughts about the 'sudo' function; if a wizard or owner of some object writes a verb using 'sudo', are there any unforeseen issues in this situation?
