fuzzball-muck/fuzzball

MPI Processes are always on #-1? (SF Issue)

tanabi opened this issue · 0 comments

The following commands:

@create bug
@desc bug={delay:20,{lit:{store:bar,foo,this}}}
look bug
@rec bug

will leave the process created by the look in the
timequeue. If no
other object is created, when the process comes out of
suspend,
it will abort with "garbage trigger". However, if
another object is
created and kept across the trigger-time, the code will
be executed
as the original object owner but (apparently) with
the permissions
of the new object owner. This seems like a potential
security flaw.

This appears to be {delay} setting the program-object
field of the
resulting MPI process to #-1 in all cases. @Kill on an
object
with MPI processes also does not work; it reports that
no processes
were found.

Looking at the source, I see, at line 287 in
add_mpi_event()
in timequeue.c, that it calls add_event with a program
arg of
NOTHING in all cases. Should this be trig instead?
Changing
NOTHING to trig seems to cause this error to disappear.
I have not
done more exhaustive testing or analysis of this
potential fix.

... or not. @ps now reports the object dbref correctly,
but the persistence across @recycle remains. Also, an MPI
process on an object that gets @chowned is not killable or
listable by the new object owner, which again seems like
a possible security flaw, unless that's supposed to be
just one of the risks of @chowning objects, which at least
sounds plausible enough.

And I'm going to stop adding so many comments now.