[MOO-Cows] FUP bugs
Just to make everyone aware, I've recently found two bugs in FUP that will
cause a server panic. If these are already known, ignore this mail.
The first is in bf_fileinfo. It has no error checking whatsoever on the
return value of getpwuid and getgrgid, and thus if one calls fileinfo() on a
file owned by a UID or GID that don't map to a name (ie, get{pwuid,grgid}
returns NULL) it will try to access a structure at NULL, thus causing a
SIGSEGV and subsequently a panic.
The second is due to the lack of any length checking whatsoever in
build_file_name and build_dir_name. If any of the FUP functions are called
with arguments that cause a path name to total more than 2048 bytes (for
example filelist("",)), it will try to tack
together the directory and file names with no length checks, thus leading to
a buffer overflow. I consider this the more dangerous of the two bugs.
I'd recommend anyone running a MOO with FUP fix these asap :)
-Sean
--
/~\ The ASCII
\ / Ribbon Campaign Sean Davis
X Against HTML aka dive
/ \ Email!
#
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: [encore] line number in callers()
On Mon, Dec 06, 2004 at 11:24:34AM -0800, Andrew Wendt wrote: > On Monday 06 December 2004 10:32, Daniel Jung wrote: > [...] > > for c in (callers()) > > block = [EMAIL PROTECTED], tostr(c[1], ":", c[2])}; > > endfor > [...] > > Now I _really_ would like to get hold of the line, not only the object and > > verb name. Callers() wouldn't reveal the line; I can't see other functions > > than raise() that could. I tried to jumble raise() into that routine, by > > producing a local, recoverable error like this: > > Using callers() won't reveal the line, but callers(1) will, right? Yes, callers(1) does show line numbers. Just checked on 1.8.1+foo2.7.4. -Sean -- /~\ The ASCII \ / Ribbon Campaign Sean Davis X Against HTML aka dive / \ Email! # This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: [encore] line number in callers()
On Mon, Dec 06, 2004 at 12:15:10PM -0800, H. Peter Anvin wrote: > Sean Davis wrote: > > > >Yes, callers(1) does show line numbers. Just checked on 1.8.1+foo2.7.4. > > > > Is it just me, or does LambdaMOO seem to be orphanned? It does seem that way. I've rewritten most of the network code in LambdaMOO 1.8.1+foo, since it was, well, ancient and disgusting. (sorry, but there hasn't been a need to use /dev/tcp on Solaris in the last, oh, ten years :P) Now the network stuff at least is sane. Too bad I've still gotta eventually rewrite the memory stuff / ref counting - it's horribly broken on Alpha, and very very poorly designed in the first place. (don't believe me? watch the infinite loop you get when trying to load a working core into a lambdamoo binary linked against electricfence..) The lambda+foo project is basically aimed at (some day) having a good MOO server based on the old code but with all the glaring problems fixed. Some day might be quite a while away, but we have improved things a bit, at least. -Sean -- /~\ The ASCII \ / Ribbon Campaign Sean Davis X Against HTML aka dive / \ Email! # This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: [encore] line number in callers()
On Mon, Dec 06, 2004 at 02:36:47PM -0800, H. Peter Anvin wrote: > Sean Davis wrote: > > > >It does seem that way. I've rewritten most of the network code in > >LambdaMOO 1.8.1+foo, since it was, well, ancient and disgusting. (sorry, > >but > >there hasn't been a need to use /dev/tcp on Solaris in the last, oh, ten > >years :P) > > > >Now the network stuff at least is sane. Too bad I've still gotta eventually > >rewrite the memory stuff / ref counting - it's horribly broken on Alpha, > >and > >very very poorly designed in the first place. (don't believe me? watch the > >infinite loop you get when trying to load a working core into a lambdamoo > >binary linked against electricfence..) > > > >The lambda+foo project is basically aimed at (some day) having a good MOO > >server based on the old code but with all the glaring problems fixed. Some > >day might be quite a while away, but we have improved things a bit, at > >least. > > > > So we have lambda+foo, GammaMOO, etc, ... it seems awful that we need > all this forking. Agreed. Very wholeheartedly. Maintaining a fork with a bunch of code changes and then picking up the (rare!!) change from the lambdamoo sf project sucks: it usually needs to be manually merged, due to, for instance, the fact that I took $Log$ out of my sources a long long time ago (all it does is bloat them, and I can run cvs log ;), among other changes. > Also, with 32-bit computers on the way out, dumping the use of symlinks > for floating-point numbers is a good thing, and similarly, we should > enable Unicode handling. Yes. In fact, it surprises me very much that I can load a core on a MSB LP64 machine (UltraSPARC in this case) and have it work just fine. Then again, UltraSPARC is not nearly as picky as Alpha when it comes to unaligned memory access. > > I guess what I'm asking is: is there any reason to not do this kind of > work against the CVS tree on Sourceforge, and to pick someone as release > coordinator, for something we can call 1.9.0 or 2.0.0? Well, I would like to say this is a good idea, but I'm not sure. Different people want different feature sets in their server... for example, I have the lists builtins (modified), both FileIO and FUP (both of which I use), and some extensions I've written myself. Many people might not want any of that. Many might want some of it. Many might want more. So... since we don't have a stable base we can just maintain patches against, we end up with a handful of forks, all of which I would be signifigantly differ from each other. Whoever ends up with the task as release coordinator... I pity them, having to put all the pieces together in a way that causes the least burning at the stake ;-) -Sean -- /~\ The ASCII \ / Ribbon Campaign Sean Davis X Against HTML aka dive / \ Email! # This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: forked moo servers
On Tue, Dec 07, 2004 at 10:06:22AM +0800, Ender wrote: > As far as all this goes, I have a few suggestions. > > First, no offence to Luke-Jr, but I've ran into a lot of compilation > glitches with GammaMoo and its code-quality isn't all that great. I'd > suggest either starting from the current Lambda CVS and merging > third-party patches for a 2.0 release or taking Foo (which has always > compiled on everything I tried it on, at least :). Well, that's good to know. It compiles on everything I can find to test it on, although it can get a little wonky on Alpha (but no more or less wonky than the "official" LambdaMOO 1.8.1) > Whether this is accomplished by taking control of the current SF > project, or creating a second one is the first decision that needs to be > made. Well, as for taking control, the thing is... nobody in that project is anything approaching active. We'd have to ask them now, and come back in 4 years to read their response. > The current SF project would have worked quite well, if patches in the > patch tracker were ever actually looked at. That said, since I see a lot > of the initial work to be simply gathering patches and improvements into > the one central codebase the first couple of developers really just need > to be decent coders who have enough time to actually look at the > patches. Agreed. > Initially I'd suggest: > * Two project admins for sanity (I elect hpa and dive) I would be more than willing - having to try and keep track of all the "neat" features I want from various server codebases and merge them without making lambda+foo an unrunnable PITA is more work than coordinating an effort in this direction, IMHO. > * Two or three developers to vet and commit patches and diffs. Sounds good, although I would up that to perhaps four or five, and add something like "and test the living out of the patches to make sure they're stable enough" > * Someone coming up with a moo-code core to regression-test the server That shouldn't be difficult. > * People making diffs Very good thing to have, that :) > Most of the development should initially be recommendations/diffs of > code to merge. As long as quality-of-code is maintained and nobody runs > out of time to merge or make patches, CVS should get up to scratch > pretty quickly. And if the regression-core is ready, then all is good. > > Furthermore, I'd suggest that 2.0 have a 'plugin' system, for > registering builtins by loading shared objects listed in a config file > (Eg, LoadModule FUP). I'm hoping that everyone has posix dlopen() > support or a wrapper by now? :) I should hope they do. And I agree with that suggestion. -Sean -- /~\ The ASCII \ / Ribbon Campaign Sean Davis X Against HTML aka dive / \ Email! # This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: forked moo servers
On Tue, Dec 07, 2004 at 02:13:07PM -0500, Garance A Drosihn wrote: > At 3:29 PM -0800 12/6/04, H. Peter Anvin wrote: > >Daniel Jung wrote: > >> > >>We are about to release a new enCore version soon. It will be > >>unicode, so we converted the database/server to unicode as well. > > > >How about this for a strawman: would anyone on this list object > >to calling LukeJr's GammaMOO "LambdaMOO 2.0", assuming ... > > Btw, where is GammaMOO these days? No idea. > I'll also note there was the EmeraldMOO project, which was another > fork off of LambdaMOO. I think several of these forks start with > the best of intentions, but then they don't build enough of a > "developer community" around them, so they fade away. That is a Yes, I've noticed that. I've managed to keep lambda+foo going solely because of the fact that there are enough bugs and warts in stock lambdamoo to keep my friends and I who work on the project busy for years ;-) > big hurdle for anyone who wants to start on LambdaMOO 2.0, too. I > could list all kinds of things that "somebody should do" as a new > version, but I have so many other projects I am busy on that I > probably wouldn't contribute much to this one. Yes, that's a problem for many people. I do almost all of the coding for lambda+foo, because thanks to my unemployed status, I have nothing but free time... -Sean -- /~\ The ASCII \ / Ribbon Campaign Sean Davis X Against HTML aka dive / \ Email! # This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: Cogito ergo sum
On Wed, Jan 19, 2005 at 02:44:49AM +0100, Daniel Jung wrote:
> Hi all
>
> [LambdaMOO 1.8.0r5]
>
> Please do this:
>
>eval me:tell(me ? "I exist" | "I don't exist")
>
> MOO objects don't seem to be "true", and I cannot see why. Could anyone
> enlighten me please. Both "banana", 14, {1,2,3} and #1 should exist.
>
> Then do this
>
>eval me:tell(OBJ ? "Objects exist" | "Objects don't exist")
>
> Type and example are returned true when it is a string (STR and
> `"banana"'), an integer (INT and `14') and a list (LIST and `{1,2,3}').
> But in OBJ, only the type is returned true; the example (be it valid or
> not) is returned false. I find this inconsistent, but maybe this is so
> by design?
>
> Last example:
>
>eval me:tell(ERR ? "Errors exist" | "Errors don't exist")
>eval me:tell(E_TYPE ? "Mismatch exists" | "Mismatch doesn't exist")
All I can say is... weird. My results seem to confirm yours, running
1.8.1+foo2.7.4:
I don't exist
Objects exist
Errors exist
Mismatch doesn't exist
... no idea.
-Sean
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: Cogito ergo sum
On Tue, Jan 18, 2005 at 07:18:04PM -0800, H. Peter Anvin wrote:
> Sean Davis wrote:
> >On Wed, Jan 19, 2005 at 02:44:49AM +0100, Daniel Jung wrote:
> >
> >>Hi all
> >>
> >>[LambdaMOO 1.8.0r5]
> >>
> >>Please do this:
> >>
> >> eval me:tell(me ? "I exist" | "I don't exist")
> >>
> >>MOO objects don't seem to be "true", and I cannot see why. Could anyone
> >>enlighten me please. Both "banana", 14, {1,2,3} and #1 should exist.
> >>
> >>Then do this
> >>
> >> eval me:tell(OBJ ? "Objects exist" | "Objects don't exist")
> >>
> >>Type and example are returned true when it is a string (STR and
> >>`"banana"'), an integer (INT and `14') and a list (LIST and `{1,2,3}').
> >>But in OBJ, only the type is returned true; the example (be it valid or
> >>not) is returned false. I find this inconsistent, but maybe this is so
> >>by design?
> >>
> >>Last example:
> >>
> >> eval me:tell(ERR ? "Errors exist" | "Errors don't exist")
> >> eval me:tell(E_TYPE ? "Mismatch exists" | "Mismatch doesn't exist")
> >
> >
> >
> >All I can say is... weird. My results seem to confirm yours, running
> >1.8.1+foo2.7.4:
> >I don't exist
> >Objects exist
> >Errors exist
> >Mismatch doesn't exist
> >
>
> RTFM. Type names are actually integers.
Yes, they are. I was merely running the suggested evals. No need to "RTFM"
at me. I'm quite aware that type names are integers. I merely found the
results of those tests... curious... for lack of a better word.
-Sean
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: How random is 'random()'? And can I seed it?
On Tue, Feb 15, 2005 at 12:38:59PM +, Dr Robert Sanderson wrote:
>
> >asked before. I wonder if anyone who is familiar with the source code
> >and randomisation techniques can tell me how it stacks up against other
> >mathematical 'random' number generator in simulating unpredictable
> >reuslts.
>
> AFAIK, it just calls out to the operating system's rand() function.
> So it's as good as your operating system's implementation.
Do you know of any Operating Systems on which lrand48() is actually better,
or even nearly as good, as random()? I know that isn't the case on NetBSD,
which has a quite good random() function, but I haven't investigate other
OS's yet. I am willing to bet the same is true on FreeBSD, OpenBSD, and
Linux, at the very least.
What's surprising to me is that the MOO server is written to prefer
{l,s}rand48(3) over {,s}random(3), even though autoconf sets HAVE_RANDOM.
the {,s}random(3) functions are only used if {l,s}rand48(3) are unavailable,
for some reason. My suspicion is that this dates back to the Heydey of
LambdaMOO on old Unices - for example, the same reason that LambdaMOO still
had code for "/dev/tcp" on Solaris in it. I'll be fixing this in LambdaMOO
1.8.1+foo as soon as I finish sending this mail. We're not quite caught up
to LambdaMOO CVS as far as things like WROGUE go - I haven't even started
merging that in - but the network code, at least, has been almost totally
redone. No reason that the random code shouldn't be brought out of the stone
age as well :-)
PS: I don't suppose anyone is interested in helping with the rather daunting
task of fixing LambdaMOO's memory allocation code? specifically, the goal is
for allocations to be able to fail without bringing down the server
($list_utils:make($maxint) for an example.) I've got plenty of experience
messing with dirty C code, but the ref counting mechanisms used by LambdaMOO
frankly baffle me: The address free()'d is almost NEVER the one returned by
malloc(), and it's left up to the OS to handle this properly. Try running a
database created on an i386, and run there for several years, on an Alpha,
and watch it explode. Try the same thing on an UltraSPARC, and watch it work
just fine. Or, if you really want to have fun, link the MOO server against
ElectricFence. It'll go into an infinite loop no matter where your database
comes from or what hardware you're using. :-P
- Sean
--
_
( ) ASCII Ribbon Campaign
X
/ \ For Plain Text Email
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: How random is 'random()'? And can I seed it?
On Tue, Feb 15, 2005 at 09:00:45AM -0500, Sean Davis wrote:
> On Tue, Feb 15, 2005 at 12:38:59PM +, Dr Robert Sanderson wrote:
> >
> > >asked before. I wonder if anyone who is familiar with the source code
> > >and randomisation techniques can tell me how it stacks up against other
> > >mathematical 'random' number generator in simulating unpredictable
> > >reuslts.
> >
> > AFAIK, it just calls out to the operating system's rand() function.
> > So it's as good as your operating system's implementation.
>
> What's surprising to me is that the MOO server is written to prefer
> {l,s}rand48(3) over {,s}random(3), even though autoconf sets HAVE_RANDOM.
> the {,s}random(3) functions are only used if {l,s}rand48(3) are unavailable,
> for some reason. My suspicion is that this dates back to the Heydey of
> LambdaMOO on old Unices - for example, the same reason that LambdaMOO still
> had code for "/dev/tcp" on Solaris in it. I'll be fixing this in LambdaMOO
> 1.8.1+foo as soon as I finish sending this mail. We're not quite caught up
> to LambdaMOO CVS as far as things like WROGUE go - I haven't even started
> merging that in - but the network code, at least, has been almost totally
> redone. No reason that the random code shouldn't be brought out of the stone
> age as well :-)
(Replying to myself here)
Fixing it so that it used random(3) with a 256-byte state was rather easy.
Unfortunately, though it compiles, the Lambda+foo MOO server doesn't work on
Solaris (this is a known problem, it's been this way ever since I rewrote
most of network.c to POSIXify things). If the problem is what I think it is,
it shouldn't be too much of a pain to fix. The only issue is that the only
Solaris-running machines I have access to are the ungodly slow sourceforge
compile farm servers, so I haven't had the motivation to sit down and fix it
yet.
Tested to compile/work with no warnings on Linux, NetBSD/i386, and
NetBSD/sparc64, so far. I'll toss a new release of the codebase out the door
as soon as I get it working on Solaris again.
- Sean
--
_
( ) ASCII Ribbon Campaign
X
/ \ For Plain Text Email
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Re: How random is 'random()'? And can I seed it?
On Tue, Feb 15, 2005 at 06:49:59PM -0500, The Mage wrote: > --- Dr Robert Sanderson <[EMAIL PROTECTED]> wrote: > > > > > asked before. I wonder if anyone who is familiar with the source > > code > > > and randomisation techniques can tell me how it stacks up against > > other > > > mathematical 'random' number generator in simulating > > unpredictable > > > reuslts. > > > > AFAIK, it just calls out to the operating system's rand() function. > > So it's as good as your operating system's implementation. > > I'm running FreeBSD 4.7, and I have no idea how good its rand() > function is nor was I aware of the existence of lrand48() and > random() in UNIX, so it looks like I am out of my depth here ... but > thanks for the tip toward the O/S, this is something I didn't > realise. It uses lrand48() by default on everything that supports it (the stock LambdaMOO, that is. Lambda+foo now uses initstate()+random()). lrand48() has been officially obsolete for twelve years now. Twelve years. Pavel Curtis needs to pop out of whereever he's hiding and bring LambdaMOO out of the /dev/tcp dark ages. Although, the sourceforge lambdamoo project could do that, too... I'd be happy to submit context diffs of the code that makes the server use random() and not lrand48()... - Sean -- _ ( ) ASCII Ribbon Campaign X / \ For Plain Text Email # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] LambdaMOO-1.8.1+foo2.8 release
Hi all, just wanted to let you know that I've put the finishing touches on enough new mods to warrant a new release of Lambda+Foo. I've fixed Solaris support, and it's been test-built and run on Solaris 9, Linux 2.4.x (slackware 8), NetBSD-current 2.99.15/i386 and NetBSD-current 2.99.9/sparc64. I'll be publishing it on the FooMOO website (www.foomoo.org) as soon as I get around to switching FooMOO to the new code and editing the html ;-) - Sean -- _ ( ) ASCII Ribbon Campaign X / \ For Plain Text Email # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[MOO-Cows] Anyone feel like hacking on the +foo source? (was Re: [MOO-Cows] Re: How random is 'random()'? And can I seed it?)
On Wed, Feb 16, 2005 at 10:01:12AM +, Neil Fraser wrote: > Sean Davis wrote: > >Twelve years. Pavel Curtis needs to pop out > >of whereever he's hiding and bring LambdaMOO > >out of the /dev/tcp dark ages. > > That would be Microsoft: > http://main.placeware.com/about_us/founders.cfm > > [Insert sound of mechanical breathing.] Okay, forget that idea :P Guess it's up to me and what volunteer coders I can muster, then. Merging in the WROGUE stuff is going to be interesting, since the source tree I maintain has had major syntax cleanup done to it and a patch against stock 1.8.1 probably has a snowball's chance in hell of applying cleanly, so it'll be a line by line deal. In any case, is anyone interested in helping out on the server-codebase side of the LambdaMOO+foo server project? Most of the work is modernization, with bug fixing thrown in whereever it can be, of course. - Sean -- _ ( ) ASCII Ribbon Campaign X / \ For Plain Text Email # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
