tmi2_fluffos_v2/
tmi2_fluffos_v2/bin/
tmi2_fluffos_v2/etc/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/ChangeLog.old/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/Win32/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/compat/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/compat/simuls/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/include/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/clone/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/command/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/data/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/etc/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/include/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/inherit/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/inherit/master/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/log/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/tests/compiler/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/tests/efuns/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/tests/operators/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/u/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/tmp/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/windows/
tmi2_fluffos_v2/lib/
tmi2_fluffos_v2/lib/adm/
tmi2_fluffos_v2/lib/adm/daemons/languages/
tmi2_fluffos_v2/lib/adm/daemons/network/I3/
tmi2_fluffos_v2/lib/adm/daemons/virtual/
tmi2_fluffos_v2/lib/adm/daemons/virtual/template/
tmi2_fluffos_v2/lib/adm/news/
tmi2_fluffos_v2/lib/adm/obj/
tmi2_fluffos_v2/lib/adm/obj/master/
tmi2_fluffos_v2/lib/adm/priv/
tmi2_fluffos_v2/lib/adm/shell/
tmi2_fluffos_v2/lib/adm/tmp/
tmi2_fluffos_v2/lib/cmds/
tmi2_fluffos_v2/lib/d/
tmi2_fluffos_v2/lib/d/Conf/
tmi2_fluffos_v2/lib/d/Conf/adm/
tmi2_fluffos_v2/lib/d/Conf/boards/
tmi2_fluffos_v2/lib/d/Conf/cmds/
tmi2_fluffos_v2/lib/d/Conf/data/
tmi2_fluffos_v2/lib/d/Conf/logs/
tmi2_fluffos_v2/lib/d/Conf/obj/
tmi2_fluffos_v2/lib/d/Conf/text/help/
tmi2_fluffos_v2/lib/d/Fooland/adm/
tmi2_fluffos_v2/lib/d/Fooland/data/
tmi2_fluffos_v2/lib/d/Fooland/data/attic/
tmi2_fluffos_v2/lib/d/Fooland/items/
tmi2_fluffos_v2/lib/d/TMI/
tmi2_fluffos_v2/lib/d/TMI/adm/
tmi2_fluffos_v2/lib/d/TMI/boards/
tmi2_fluffos_v2/lib/d/TMI/data/
tmi2_fluffos_v2/lib/d/TMI/rooms/
tmi2_fluffos_v2/lib/d/grid/
tmi2_fluffos_v2/lib/d/grid/adm/
tmi2_fluffos_v2/lib/d/grid/data/
tmi2_fluffos_v2/lib/d/std/
tmi2_fluffos_v2/lib/d/std/adm/
tmi2_fluffos_v2/lib/data/adm/
tmi2_fluffos_v2/lib/data/adm/daemons/
tmi2_fluffos_v2/lib/data/adm/daemons/doc_d/
tmi2_fluffos_v2/lib/data/adm/daemons/emoted/
tmi2_fluffos_v2/lib/data/adm/daemons/network/http/
tmi2_fluffos_v2/lib/data/adm/daemons/network/services/mail_q/
tmi2_fluffos_v2/lib/data/adm/daemons/network/smtp/
tmi2_fluffos_v2/lib/data/adm/daemons/news/archives/
tmi2_fluffos_v2/lib/data/attic/connection/
tmi2_fluffos_v2/lib/data/attic/user/
tmi2_fluffos_v2/lib/data/std/connection/b/
tmi2_fluffos_v2/lib/data/std/connection/l/
tmi2_fluffos_v2/lib/data/std/user/a/
tmi2_fluffos_v2/lib/data/std/user/b/
tmi2_fluffos_v2/lib/data/std/user/d/
tmi2_fluffos_v2/lib/data/std/user/f/
tmi2_fluffos_v2/lib/data/std/user/l/
tmi2_fluffos_v2/lib/data/std/user/x/
tmi2_fluffos_v2/lib/data/u/d/dm/working/doc_d/
tmi2_fluffos_v2/lib/data/u/l/leto/doc_d/
tmi2_fluffos_v2/lib/data/u/l/leto/smtp/
tmi2_fluffos_v2/lib/doc/
tmi2_fluffos_v2/lib/doc/driverdoc/applies/
tmi2_fluffos_v2/lib/doc/driverdoc/applies/interactive/
tmi2_fluffos_v2/lib/doc/driverdoc/concepts/
tmi2_fluffos_v2/lib/doc/driverdoc/driver/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/arrays/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/buffers/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/compile/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/ed/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/filesystem/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/floats/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/functions/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/general/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/mappings/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/numbers/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/parsing/
tmi2_fluffos_v2/lib/doc/driverdoc/lpc/constructs/
tmi2_fluffos_v2/lib/doc/driverdoc/lpc/preprocessor/
tmi2_fluffos_v2/lib/doc/driverdoc/lpc/types/
tmi2_fluffos_v2/lib/doc/driverdoc/platforms/
tmi2_fluffos_v2/lib/doc/mudlib/
tmi2_fluffos_v2/lib/ftp/
tmi2_fluffos_v2/lib/include/driver/
tmi2_fluffos_v2/lib/log/
tmi2_fluffos_v2/lib/log/driver/
tmi2_fluffos_v2/lib/obj/net/
tmi2_fluffos_v2/lib/obj/shells/
tmi2_fluffos_v2/lib/obj/tools/
tmi2_fluffos_v2/lib/std/adt/
tmi2_fluffos_v2/lib/std/board/
tmi2_fluffos_v2/lib/std/body/
tmi2_fluffos_v2/lib/std/fun/
tmi2_fluffos_v2/lib/std/living/
tmi2_fluffos_v2/lib/std/object/
tmi2_fluffos_v2/lib/std/shop/
tmi2_fluffos_v2/lib/std/socket/
tmi2_fluffos_v2/lib/std/user/
tmi2_fluffos_v2/lib/std/virtual/
tmi2_fluffos_v2/lib/student/
tmi2_fluffos_v2/lib/student/kalypso/
tmi2_fluffos_v2/lib/student/kalypso/armor/
tmi2_fluffos_v2/lib/student/kalypso/rooms/
tmi2_fluffos_v2/lib/student/kalypso/weapons/
tmi2_fluffos_v2/lib/u/l/leto/
tmi2_fluffos_v2/lib/u/l/leto/cmds/
tmi2_fluffos_v2/lib/www/errors/
tmi2_fluffos_v2/lib/www/gateways/
tmi2_fluffos_v2/lib/www/images/
tmi2_fluffos_v2/old/
tmi2_fluffos_v2/win32/
#d/TMI/boards/driverboard.c
ob_data (["short":"@@query_short","long":"@@query_long","short.text":"The MudOS driver board","long.text":"This is a bulletin board. For information on how to use it, use `help board'.
","silent_look":1,"id":({"board","bulletin board",}),"last_location":0,])
messages ({(["title":"stack security and uids","poster":"Leto","time":828740112,"body":"Having permissions being granted by multiple rulings isn't 
going to make security any easier and safer :)

But I think Hanzou means to use uids and also use lots of
origin and previous_obj calls to even more limit access.

However, you'd be suprised how much you can do with bind and fp's :)

Leto
","id":46,]),(["title":"Re: stack security and uids","poster":"Rust","time":828765799,"body":"On Fri Apr  5, Leto wrote:
> Having permissions being granted by multiple rulings isn't 
> going to make security any easier and safer :)
> 
> But I think Hanzou means to use uids and also use lots of
> origin and previous_obj calls to even more limit access.
> 
> However, you'd be suprised how much you can do with bind and fp's :)
> 
> Leto

No, actually, you could use UIDS to tag permissions onto objects, and
then use the call stack to analyze them.

","id":47,]),(["title":"Re: stack security and uids","poster":"Leto","time":828888042,"body":"On Sat Apr  6, Rust wrote:
> No, actually, you could use UIDS to tag permissions onto objects, and
> then use the call stack to analyze them.
> 

That's basically what some functions already do. However, as I said,
it's always performance against security. Checking the entire
call-chain AS WELL as uids can be quite costly.
That, and ofcourse the query/set with it's enormous load. If you
want to speed up a tmi based mud, redo query and set :)

Leto
","id":48,]),(["title":"Re: stack security and uids","poster":"Rust","time":828896828,"body":"On Sun Apr  7, Leto wrote:
> On Sat Apr  6, Rust wrote:
> > No, actually, you could use UIDS to tag permissions onto objects, and
> > then use the call stack to analyze them.
> > 
> 
> That's basically what some functions already do. However, as I said,
> it's always performance against security. Checking the entire
> call-chain AS WELL as uids can be quite costly.
> That, and ofcourse the query/set with it's enormous load. If you
> want to speed up a tmi based mud, redo query and set :)
> 
> Leto

I've never seen a function here check the whole call stack.

It's not performance vs. security: immagine a mud where every insecure
operation fails.  Doesn't take much of a performance hit to return 0
all over the place in the master.

You really underestimate the speed of LPC if you're worried about
verification of a call stack that rarely gets more than 5 or 6 items
deep being slow.
","id":49,]),(["title":"Re: stack security and uids","poster":"Hanzou","time":828897540,"body":"On Sun Apr  7, Leto wrote:
> That's basically what some functions already do. However, as I said,

on tmi-2 ?

grep previous_object(-1) /adm/daemons/*
                         /std/*
                         /adm/obj/*

i sure don't find much
","id":50,]),(["title":"compilation problems","poster":"Chandos","time":829225344,"body":"Guys,

I am having a bit of trouble compiling the 21.7r10 driver on a sparc 2
System V release 4.0 with Solaris 2.x..
First error i get during compile is: 

make: Fatal error: Don't know how to make target `malloc.o'

If i continue the compilation past this, i crash at the minor Makefiles, caus
they use ranlib, and i do not have this on my system.  (I should go ftp it from somewhere i guess)  Another problem i had with subsequent versions of the driver was a missing header file: rusage.h (But commenting this out solved that).

Question: whatever happened to the -lresolv options for Extralibs for SunsOS??
Is this no longer required? It exists in 21.6*.

Thanx people
-Chandos-
","id":51,]),(["title":"ok, same diff, different version","poster":"Chandos","time":829229168,"body":"Ok,

I tried driver 20.21p ? the one thats packed with TMI2-1.2.
All compiled fine (with missing rusage.h) up untill addr_serv :

gcc  -DBSD_COMPS -O2 -fomit-frame-pointer -fstrength-reduce        -pipe  -c addr_server.c
addr_server.c: In function `conn_data_handler':
addr_server.c:484: `FIONREAD' undeclared (first use this function)
addr_server.c:484: (Each undeclared identifier is reported only once
addr_server.c:484: for each function it appears in.)
*** Error code 1
make: Fatal error: Command failed for target `addr_server.o'

Any ideas?
-C-
","id":52,]),(["title":"new","poster":"Chandos","time":829285664,"body":"OKOK,
The mud works ok without addr_server, and i managed to compile another
version addr_server which works fine anyway..

Latest problem: On the mud, i cannot do: su, or finger.
What driver/mud configuration could have stuffed up the connection info?

thanks in advance
-Chandos-
","id":53,]),(["title":"Re: new","poster":"Leto","time":829340705,"body":"On Fri Apr 12, Chandos wrote:
> OKOK,
> The mud works ok without addr_server, and i managed to compile another
> version addr_server which works fine anyway..
> 
> Latest problem: On the mud, i cannot do: su, or finger.
> What driver/mud configuration could have stuffed up the connection info?
> 
> thanks in advance
> -Chandos-

Check the path settings. You might not have those cmds in your
path.

(check with \"which su\" etc)

su is in /cmds/wiz, finger in /cmds/std (If you don't have finger
you're either dead and ghostly, or have a real problem :)

Leto
","id":54,]),(["title":"finger/su","poster":"Chandos","time":829358122,"body":"Nono, my paths are fine..

When i type su i get:
Su: Could not restore requested user.

and when i type: finger diablo i get:
Finger: There is no such user.

But the user DEFINATELY exists.  
IE: It cannot resotre connection to ANY user who is not logged on..

Any ideas?
MANY Thanx
-C-
","id":55,]),(["title":"Re: finger/su","poster":"Hanzou","time":829359332,"body":"On Sat Apr 13, Chandos wrote:
> Nono, my paths are fine..
> 
> When i type su i get:
> Su: Could not restore requested user.
> 
> and when i type: finger diablo i get:
> Finger: There is no such user.
> 
> But the user DEFINATELY exists.  
> IE: It cannot resotre connection to ANY user who is not logged on..
> 
> Any ideas?
> MANY Thanx
> -C-

perhaps u defined AUTO_SETEUID ? (u shouldn't)
","id":56,]),(["title":"Another MudOS Compile Prob","poster":"Lucas","time":829382218,"body":"Will these problems never stop? I am trying to compile v22a25
and it gives me these errors:
adm/obj/master.c line 75: == always false because of incompatible types ( string
 vs int ).
adm/obj/master.c line 350: != always true because of incompatible types ( string
 vs int ).
adm/obj/master.c line 385: == always false because of incompatible types ( strin
g vs int ).
No error handler for error: *Error in loading object '/adm/obj/master'
program: (none), object: (none), file: (none)
The simul_efun (/adm/obj/simul_efun) and master (/adm/obj/master) objects must b
e loadable.

I have the EXACT same copy of /adm/obj/master.c as here, so I have
no clue whats wrong (I am gueesing a problem in options.h)

Well, thanks in advance (like always)
	-lucas-
","id":57,]),(["title":"Re: Another MudOS Compile Prob","poster":"Hanzou","time":829416618,"body":"On Sat Apr 13, Lucas wrote:
> Will these problems never stop? I am trying to compile v22a25
> and it gives me these errors:
> adm/obj/master.c line 75: == always false because of incompatible types ( string
>  vs int ).
> adm/obj/master.c line 350: != always true because of incompatible types ( string
>  vs int ).
> adm/obj/master.c line 385: == always false because of incompatible types ( strin
> g vs int ).

this looks like origin()'s fault.  it now returns strings.  perhaps you forgot
to copy the driver's include directory to the mudlib /include/driver

> No error handler for error: *Error in loading object '/adm/obj/master'
> program: (none), object: (none), file: (none)
> The simul_efun (/adm/obj/simul_efun) and master (/adm/obj/master) objects must b
> e loadable.
> 
> I have the EXACT same copy of /adm/obj/master.c as here, so I have
> no clue whats wrong (I am gueesing a problem in options.h)

75, 350, and 385 on team-aye's master.c are all exactly 2 lines before a use
of origin(), i don't think you have the EXACT same copy

> 
> Well, thanks in advance (like always)
> 	-lucas-

btw this is not a mudos compile problem
","id":58,]),(["title":"Re: Another MudOS Compile Prob","poster":"Lucas","time":829420704,"body":"Opps. Yeah. It's isn't a compile problem. It's a getting to run
now problem. Sorry about thats mistake.

Anyways, I thought I had an exact copy, and now the errors are two
lines down (still with origin).

It still doesn't work, and I have no idea how to fix it now.
	-lucas-
","id":60,]),(["title":"Re: Another MudOS Compile Prob","poster":"Lucas","time":829421645,"body":"On Sat Apr 13, Lucas wrote:
> Opps. Yeah. It's isn't a compile problem. It's a getting to run
> now problem. Sorry about thats mistake.
> 
> Anyways, I thought I had an exact copy, and now the errors are two
> lines down (still with origin).
> 
> It still doesn't work, and I have no idea how to fix it now.
> 	-lucas-
Yeah! I solved my own problem. The old version of origin.h that I
had used numbers instead of the string that tmi's origin.h had,
I copied it and now it works!

Yeah. Now if anyone needs help _I_ can actually help!
	-lucas-
","id":61,]),(["id":62,"body":"On Fri Apr 12, Chandos wrote:
> OKOK,
> The mud works ok without addr_server, and i managed to compile another
> version addr_server which works fine anyway..
> 
> Latest problem: On the mud, i cannot do: su, or finger.
> What driver/mud configuration could have stuffed up the connection info?
> 
> thanks in advance
> -Chandos-
We had this problem on LW....

if it is the same problem, you don't have your save extention set correctly.

in your mudlib.h append the following lines:
#ifndef __SAVE_EXTENSION__
#define __SAVE_EXTENSION__ SAVE_EXTENSION
#endif

See if that fixes ya.

Crusader
","time":832051298,"poster":"Crus","title":"Re: new",]),(["id":63,"body":"> We had this problem on LW....
> 
> if it is the same problem, you don't have your save extention set correctly.
> 
> in your mudlib.h append the following lines:
> #ifndef __SAVE_EXTENSION__
> #define __SAVE_EXTENSION__ SAVE_EXTENSION
> #endif
> 
> See if that fixes ya.
> 
> Crusader

It's better to search and replace all occurances of the olf
SAVE_EXTENSION to __SAVE_EXTENSION__

Also, if you do decided on the above fix, make sure mudlib.h
is a global include file specified in the config.mudname

Leto
","time":832078155,"poster":"Leto","title":"Re: new",]),})
id_ref 63