Object property rights - capability security

[C Oda]

In the LambdaMoo Programmers' Manual[0], it is written:

Every defined property (as opposed to those that are built-in) has an owner and a set of permissions for non-owners. The owner of the property can get and set the property's value and can change the non-owner permissions. Only a wizard can change the owner of a property.

Historically, wasn't/isn't identity-based ownership a huge problem, requiring a lot of involvement by wizard operators?

In the Capability (key)-based security discipline[1], access rights are not assigned to one or multiple identities, but are reified in objects called keys, which, much like in the real world, can be passed around and copied. The only thing that is ever owned are keys, and keys to lists of keys - all other objects are accessed through this network.

Is anyone aware of a MUD that uses this access right paradigm?

[0] https://www.hayseed.net/MOO/manuals/ProgrammersManual.html

[1] https://en.wikipedia.org/wiki/Capability-based_security

[Michael Munson]

Yes, but this is baked into the MOO at such a low level that it would be difficult, although not impossible, to change. And the payout for making that change is very small because there are other aspects of MOO permissions, namely the verb permissions, that function exactly the same and would be very difficult to adjust.

--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/57af29db-1925-4650-80af-b273fcef24ff%40googlegroups.com.

[Michael Munson]

Oh, never answered your question. No, not really. A slightly better implementation of access rights is implemented in the ColdC M* in which properties are called object variables and by default they are private so only the object methods can access them. This necessitates you creating getter/setter methods for each “property” that needs to be externally accessible.

On Fri, Mar 27, 2020 at 11:36 AM C Oda <ArndtS...@freenet.de> wrote:

[Steven Owens]

I don't recall there being a lot of problems with identity-based ownership/permissions. Can you give some examples?

I'm familiar with capabilities from the E language but I don't know of any programmable MUDs that support them.

[C Oda]

I don't recall there being a lot of problems with identity-based ownership/permissions. Can you give some examples?

Most user-extensible MUDs seem to divide users into classes, normal players (without edit permissions) and creators/administrators/wizards (with edit permissions, they can create, modify or delete all objects). On open servers with many players, griefing problems (object spamming, stealing, destruction) will inevitably result.

I'm familiar with capabilities from the E language but I don't know of any programmable MUDs that support them.

Kevin Reid is apparently creating this: http://wiki.erights.org/wiki/Den