Subject: Permissions system of moo

From: Byron Montgomerie <[email-masked]>
Date: Tue, 16 Feb 1993 07:37:51 -0800

I was contemplating the permissions system of the moo language and I was
wondering about the feasibility of separating the perms of the owner from the
id of the owner.  The set_task_perms system of changing task permissions seems
to be a bit limiting to me.  What I have in mind exactly is the user/group/
other permission system of unix translated into a form for moo.

Instead of a verb just having a owner field perhaps it could also have a group
field, from a group list defined on a system object. Entries such as wizard
programmer builder guest rpg etc...

The motivation behind this is to separate the ownership from the permissions
issue of calling verbs. That may not be the best reason for having such a
system but I think it would be handy for other reasons as well, group ownership
by programmers for projects comes to mind.

[To Pavel Curtis] Would this be extremely hard to do?  Would it be possible to
do it in such a way as to retain compatibility with current cores? Pros? Cons?

Byron...
 __________________________________________________________________________
| __  ///    "Byron Montgomerie"  Internet: [email-masked]   __  /// |
| \\\///      "Does anybody here remember Vera Lynn?               \\\///  |
|  \XX/        Remember how she said that we would meet again,      \XX/   |
|  Amiga       some sunny day..." -- Pink Floyd --                 Amiga   |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 24 Feb 1993 09:59:49 -0800

> Date:	Tue, 16 Feb 1993 07:37:51 -0800
> From:	Byron Montgomerie <[email-masked]>
> 
> id of the owner.  The set_task_perms system of changing task permissions
> seems to be a bit limiting to me.  What I have in mind exactly is the
> user/group/ other permission system of unix translated into a form for moo.
> 
> Instead of a verb just having a owner field perhaps it could also have a
> group field, from a group list defined on a system object. Entries such as
> wizard programmer builder guest rpg etc...
> 
> system but I think it would be handy for other reasons as well, group
> ownership by programmers for projects comes to mind.
> 
> [To Pavel Curtis] Would this be extremely hard to do?  Would it be possible
> to do it in such a way as to retain compatibility with current cores? Pros?
> Cons?

I don't think I understand the motivation behind your suggestion, but I do have
some comments on it.  First, I believe that it is very important that the
permissions with which a verb runs be the same as the set of people who can
change the verb's code.  Otherwise, there is no responsibility built into the
system and trojan horses become too easy.

Rather than add groups to the system, I intend simply to remove the current
restriction that only `players' can own things.  This will open up the
possibility of creating what I call `corporations,' entities that own things
and have their own separate identities from the set of players who are their
`members.'  Simple DB code would keep track of who's allowed to work on behalf
of what corporations and, also, of which corporation a given player is acting
for at any given moment.  In essence, this allows the same kind of
collaboration as a bunch of players getting together and creating a
pseudo-player that they share, but much more conveniently.

	Pavel

---

From: Judy Anderson <[email-masked]>
Date: Wed, 24 Feb 1993 11:02:33 -0800

>restriction that only `players' can own things.

Does this mean that it will be possible to set_task_perms to a
non-player object?  Hurrah, bugs that make puppets not able to use the
"take" verb go away!

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 24 Feb 1993 11:12:26 -0800

> Date:	Wed, 24 Feb 1993 11:02:33 -0800
> From:	Judy Anderson <[email-masked]>
> 

Right.

---

From: Roger Crew <[email-masked]>
Date: Wed, 24 Feb 1993 16:58:36 -0800

In order to make corporations work, one more thing is needed apart from
dropping the only-players-own-things restriction.  This has to do with
the fact that set_task_perms() can't currently be replaced by any
in-db verb call since no verb call can affect the permissions of the
calling verb.

I'll put the simple, radical proposal first:

  (1) set_caller_perms()

Suffice it to say that this had better be wizard-only.
The more mild, but more complicated proposal is

  (2) a server hook for set_task_perms().  

I.e., if I do set_task_perms(#37), and #37 isn't a player (and perhaps
even if it is --- may as well completely divorce the concepts of
permission and login ability), there needs to be

 (a) some kind of :perms_accept() hook on #37 that gets called
     to determine if the caller is one of the people permitted 
     to hack on #37.
     Either that or there has to be a hardwired rule for the 
     server to follow (look in #37.hackers), but this would be 
     less flexible.

 (b) a way to ensure that (or at least to tell whether) :perms_accept 
     is being called from a set_task_perms() or from an ordinary verb.
     I'll revive my earlier suggestion about allowing server-hooks like
     enterfunc() and initialize() to be called even when they're -x

 (c) some way for a wizard to bypass a hostile :perms_accept() verb 
     on an annoying player or corporation.  
     (I suppose there's always delete_verb() but that's gross...)

--
Roger Crew
Internet:   [email-masked]
LambdaMOO:  Rog

---

From: Larry Masinter <[email-masked]>
Date: Thu, 25 Feb 1993 08:51:01 -0800

I see no harm in making corporations .players, except that players()
would get longer and contain objects that were not children of
$player.

---

From: Judy Anderson <[email-masked]>
Date: Thu, 25 Feb 1993 09:12:55 -0800

From: Larry Masinter <[email-masked]>

But you don't get the advantage of being able to have verbs owned by
non-players working completely correctly, thus you would continue to
have problems when players were toaded, the variable "player" was set
to a non-player object, etc.  Unless you meant corporations could be
*either* players or non-players...  In which case my objection is moot.

---

From: Roger Crew <[email-masked]>
Date: Thu, 25 Feb 1993 16:13:44 -0800

>   would get longer and contain objects that were not children of

[...Actually, I think players() is a pretty useless function.  Given the
number of players we currently have on Lambda, we may as well be
grovelling through the DB testing is_player() on every object...]

Note however that you don't want corporations to be players that can
CONNECT, since there is no possibility of accounting for what a shared
player does once connected.  For example, if I happen to know the
Grandmaster password (Grandmaster owns G7&Gemba's RPG system on
LambdaMOO), I simply login as Grandmaster, do arbitrary damange to
Grandmaster owned things, and there's no way for anyone to know that
it was me; it could have been any of the people who know the
Grandmaster password.  There's also the problem that anyone who knows
the Grandmaster password can change it.

It's much better to require players to login as themselves and use a
modified set_verb_code()/set_foo_info()/set_task_perms() to do their
dirty work.  Then, there is the possibility of keeping track of who
does what, should one actually want to.  One can also implement much
finer notions of access control (e.g., granting access without giving
away the store).

The basic principle here is that if password really is supposed to be
a means to establish identity, then a given password should point to a
SINGLE real person.  

Note that if one has a class of "players" that never log in, then, in
addition to all of the player verbs that become useless (mail reading,
etc...), we have a whole set of "player" builtin functions
(connected_seconds(), idle_seconds(), connection_name(),
connected_players()... ) that are likewise meaningless.

What we really have here is a distinction between the concepts of
identity and permission.  The existence of shared players, or for that
matter the existence of wizard characters that are distinct from the
mild-mannered-player characters, suggests that this is a useful
distinction.