Menu
▾
▴
#240 Dodgy HOME metalink
On a muck with the 'gohome' command set (where gohome
is the usual metalink global exit to *HOME*) do the
following.
@crea gh_toy
@crea ride_toy
@link ride_toy=gh_toy
@set ride_toy=x
@flock ride_toy=me
drop ride_toy
drop gh_toy
look
@force ride_toy=gohome
look
After the first look you'll see the ride_toy and gh_toy
in the room with you. After forcing the ride_toy to
gohome, you will find that the ride_toy is still in the
room with you while the gh_toy has relocated to #0. A
quick @tel later and you're sitting in #0. This will
work for mortals and wizards. Neither ride_toy nor
gh_toy are linked to #0.
Logged In: YES
user_id=7718
Changing this back to security, as drop me=(any room in #0)
from #0 will allow people to bypass most security checks.
I've changed most of the places that allowed that to drop to
player_start instead, but there's always the possibility
that I missed one.
This is a kind of parent/home loop check failure, and I'm
not sure how best to resolve it. Assigning to Revar to look
at and think about.
Regardless, it needs to get fixed. I don't think we have
any references on what the flags "should be" on #0, and I'm
pretty certain that most mucks have it unsecured.
Logged In: YES
user_id=175712
So here's what happens, it looks like:
a) Thing A is homed to thing B. Thing A executes gohome.
b) move.c:trigger() looks up the destination of the action,
and sees that it's HOME. Converts HOME into thing B.
c) trigger() looks at the type of thing B. It's a thing,
so that must mean it should go to the location of the
exit.
d) The location of the exit is #0, so thing A goes to #0.
Logged In: YES
user_id=175712
Temporary fix for security breakage in CVS, pending more
well-defined semantics of having a thing gohome to another
thing.
Logged In: YES
user_id=7718
Semantics for a thing to gohome to another thing: move
object into thing, leave it there. (We already have
@conlock, which means that things can act as containers. If
someone allows a Thing to be linked to...
Link target: THING
Player: Not valid (Do not allow even if Thing is set V)
Exit : move player into thing, if thing is Jump_OK and
roomenv(thing) is Jump_OK and player is Jump_OK and thing is
set Vehicle.
Program: Not Applicable
Thing : Move victim to contents of thing.
Room : Follow normal 'dropto' rules, dropto is contents of
thing (@create Dumpster; @link here=Dumpster)
Any qualms with these proposed semantics?
Logged In: YES
user_id=175712
Sounds good to me. Will implement in move.c if no
objections are raised within a few days.
Logged In: YES
user_id=7718
Thought:
If there's @conlock, then the attempted link operation
should be checked against it (unless player is unquelled
wizard). Specifically, the OWNER(player) attempting to make
the link should be checked against the conlock. If the lock
fails, "You cannot create a link to that object."
I don't know if there are any other situations that need to
be looked at (M3 can create links regardless, M2 is based on
the current uid of the process).
Do make sure to check for a parent_loop_paradox, which is
what I think is allowing this error in the first place -- if
it exists there, abort the move attempt.
Logged In: YES
user_id=175712
parent_loop_paradox has nothing to do with the original
error; the original error caused the target object to be
moved to the location of the exit, plain and simple. It
just so happens that global gohome is usually on #0.
On second thought, this proposal would make linkability to
an object oddly overloaded:
- Linking a thing to a thing lets you send the source to
the target.
- Linking a room to a thing lets you send the contents
of the source (things only) to the target.
- Linking an exit to a thing lets you send the target to
the location of the exit.
- Linking a program to a thing is impossible.
... but on third thought, room-to-thing droptos already
pretty much work that way. I don't think they check
@conlock, instead using the ordinary controls-or-A check for
link targets, so I would think that homing thing-to-thing
links should do the same thing.
Logged In: YES
user_id=7718
Originator: NO
Linking an exit to a thing should send the player to the linked-to-thing if such a move is allowed, NOT to the attachment point (location) of the exit. Otherwise it should be a "cannot move that way" error.
The current semantics of moving to location(exit) are broken, it should be target(exit). And #-3 should ALWAYS devolve to getlink(object) || getlink(OWNER(object)) || tp_player_start.