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:
- Re: Security
- From: phantom@baymoo.sfsu.edu (Richard Connamacher)
Home |
Subject Index |
Thread Index