MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: Security



Richard Connamacher wrote:
> 
> Find all the verbs on $player that allow them to teleport things (like
> @move), and move them to $builder, and @rmverb them from $player.  Then
> just set up some rules to programmers saying that they're not allowed to
> make things that give players the ability to teleport, without first asking
> the wizzen.
I changed @move to check for owner both in dobj and iobj.
What about @set me.location?

> The LambdaMOO programmer's manual is correct, but not in the way that
> you're thinking.  Players cannot change their names, unless the core gives
> them the ability to change their names.  Ie if you can't change your .name
> property, but I am a wiz, and I make a verb that changes your name property
> for you, to whatever you wanted it to change to, such as @rename, then, as
> far as the MOO's concerned, _I_ am the one who is changing your name.
> you're just the one who typed the verb to do it.  That's how @rename works.
You mean that this can be solved adding set_task_perm at the beginning of 
@rename @set and @edit?
I want people to be able of changing their objects names and so, but not 
themselves...
 
> Stock players shouldn't be able to @chparent themselves, that is a verb
> left to $builder.  make sure that new players are kids of $player, and not
> $builder.
The same problem appears with this verb, again set_task_perm???
> 
> >Now players owners are themselves, is this correct?
> 
> True, players generally own themselves, although there is no hard and fast
> rule saying that this must be so, although in LambdaCORE, it'll screw up a
> lot of things if players don't own themselves.

So I have three options I think...
-Change owner of the players to a wizard (losing mail and so?)
-Use $server_options    (??????)
-Edit or remove related verbs, adding ser-task-perm.
Right?
 
> >Another one:
> >Should I change the f bit of #1 to off and propagate to childs?

> I'm not sure what you mean, but I'd suggest just keeping #1 fertile.
I wanted to avoid building any but generics to builders, from now...


> A lot of people find that.  I'd suggest for you to go to one of the already
> established MOOs, there's a lot of people there who will help you learn how
> to program MOO and how everything works.  It's always good to put off
> building a high speed jet until you know how they work, and the same thing
> applies to MOO.  :-)

I ll do that, many thanks.


References:

Home | Subject Index | Thread Index