1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
Do before release:
*
These are easy things I recommend to anyone interested in getting
their feet wet:
* connect to moo and diconnect yeilds ugliness in log. (Errors)
* 'get down' works in perlmoo - exits should not be pickup-able.
- I think the way to go is to make a sessile object and make exits
subclass it. Also makes furniture work.
* Make it work with -w with no warnings.
* Make give command use its own verb, instead of piggybacking on verb_put,
so it can have a slightly more appropriate message.
* Fix Thing.pm's AUTOLOAD so it detects when you try to run a in-db method
that has no code, so it doesn't spit out junk and put a VerbCall in the
caller's properties..
* Modify dig so it checks return codes when adding exits to rooms - if
permission is denied, it needs to delete the exit it tried to create and
warn the user.
* Look at perl -ne "print if /\w+->\w+->/" * in many of these, we need to
make sure $1 returns a true value before going to to look at the whole
thing. There's only 150 to check! ;-)
* Find places maked FIXME and TODO in the code and fix them.
* Implement an ed-like editor (being worked on).
These are security-related things:
* It *may* be possible for a programmer to fiddle with contents of the
methods and verbs hashes of an object they don't own, by calling
properties on those objects. Those object probably need permissions and
closures added to them. Check.
* Here's a nasty - I was writing verb_verbcode and I noticed that when I
called $thing->methods, I sometimes got back a reference to the parent's
hash - which I could *modify*. Basically, anytime a reference is returned,
we can modify what it refers to. This needs fixing. Maybe just don't ever
return a reference? Ie, make a copy before returning the value so they get
a reference to a copy of the value? Hm, I think that would break too many
things. Instead, we should probably make a SafeHash object, and a SafeList
object, that use closures :-(
* When in-db code calls the super() method to run overridden methods, there
is a potential secuity hole. Since the in-db code is running inside a
safe, we really can't break out and use a different safe for the super()
code. So what it does is makes a new safe inside the old. (Analagous to
using chroot, and then running chroot again.) The problem with this is
that if the child in-db method code wants to, it can fiddle with that
namespace, and potentially make the parent code do weird things, or even
replace it with new code that will run as the parent owner.
* Wouldn't it be possible to write an in-db method that changes its owner
to someone else?
These are harder things:
* Can't override methods of an object, because you really make a method_safe
command. Anyway, because AUTOLOAD comes last. 2 big problems.
* If something running in a Safe tries to make an Error, that fails because
Error::new isn't exported into the safe.
* There's a help problem. When upgrading, if help text is modified, the mods
don't take effect. I guess this applies to other fields too, but it's most
obvious with help text. The best solution I can think of is to have an
"old" db, and a "new" db, and look at the user's db... if their db contains
a value verbatim from the "old" db, then use the one from the "new" db
instead, otherwise, keep whatever they have. But this is technically hard
to do, becuase loading 2 db's seperately was never in the design of
perlmoo.
* The object closure sub is a real mess. Re-write, or something. In
particular, it will crash and burn if an object has a parent property that's
not an object. Maybe: Change object properties to each be an object, that
will have permissions, and will automatically do the inheritcance thing
and the merging, and all that nastiness.
* Make all methods of Things be in-db methods? Maybe. At least them I could
implement my own clean inheritance that worked in safe's..
* The question_callback stuff will sometimes ask silly questions. For example,
create $thing named ball
create ball named ball
create ball named ball
The third command makes it ask you 2 questions, once for the d.o. (needed),
but also once for the i.o (not needed). Is it just a symptom of the d.o.
and i.o. maybe being looked up too early?
* Items from BUGS
|
