#d/TMI/boards/generalboard.c
ob_data (["last_location":0,"silent_look":1,"id":({"board","bulletin board",}),"long.text":"This is a bulletin board. For information on how to use it, use `help board'.
","short":"@@query_short","short.text":"General purpose bulletin board","long":"@@query_long",])
messages ({(["title":"Re: gwiz and code :emote","poster":"Hideyoshi","time":819259811,"body":"On Mon Dec 18, Leto wrote:
> On Sun Dec 17, Hideyoshi wrote:
> 
> > Also...how do I add new intramud channels and delete old ones?  I tried
> > editing /include/channels.h, /adm/channels, and /adm/daemons/channels.c,
> > but I still have the same channels I had before.
> 
> It's in /adm/etc/channels
I meant /adm/etc/channels...
> 
> > Also, in order for /include/channels.h to have #undef NO_NEW_CHANNELS, you
> > have to add  \"string flag, channels;\" to /cmds/wiz/_channels.c, otherwise
> > you get a bunch of \"undefined variable\" errors when you update.
> 
> I tried it here, but it worked fine. Maybe you messed up channels
> yourself ?
Hmmm...never touched _channels.c before today when I discovered that the
two variables were never defined...  Dunno...

-Hideyoshi
> 
","id":91,]),(["title":"MASTER_ONLY","poster":"Farrow","time":819266511,"body":"What gives user.c access to change MASTER_ONLY stuff?  I want to make
a stat file that will change stats, but I don't want to make the stats
PUBLIC access.  What do I have to do here?  I noticed that user.c doesn't
have ROOT_UID (obviously) *grin* so why does it work?

Farrow@Lost Worlds
","id":92,]),(["id":93,"body":"I changed group-names on Luvigana, and also put uid's in a separate file.
Everything seem to work like before (which is should), except for one
small detail. The mud 'loses' its data now and then.
Once in a while i'm a new user when i try to login, and if I try a few
times i can login as normal. Same thing with commands, like 'cd'.
When i type 'cd' it gets me to my homedir, but once in a while i end up
in /doc which is the hardcoded path if no other dir were accessible..
What may cause this? Any suggestion is appreciated.

Dino@Luvigana
","time":819272539,"poster":"Dino","title":"Loss of data",]),(["id":94,"body":"On Mon Dec 18, Farrow wrote:
> What gives user.c access to change MASTER_ONLY stuff?  I want to make
> a stat file that will change stats, but I don't want to make the stats
> PUBLIC access.  What do I have to do here?  I noticed that user.c doesn't
> have ROOT_UID (obviously) *grin* so why does it work?
> 
> Farrow@Lost Worlds

At Earth we solved this by making a stat daemon. Objects can then call
the daemon, and the daemon (running with root) can decide wether or not
to actually execute the request.
It also logs stat changes to /log/adm, so we can see if a player
suddenly advances beyond the physical limits in a few hours
(Eg: abusing a bug, or a wiz interfering :)

Leto
","time":819290962,"poster":"Leto","title":"Re: MASTER_ONLY",]),(["id":95,"body":"I am not sure what causes this. I've heard more people complain
about these features. It doesn't happen here. It might be a 
architectural feature of the mudos driver. Are your unning v21.6 or
above ?   

If so, what are your options.h (or local_options)

Leto
","time":819291064,"poster":"Leto","title":"Re:data loss, players ont saved etc",]),(["title":"Re: Re:data loss, players ont saved etc","poster":"Rust","time":819299614,"body":"On Mon Dec 18, Leto wrote:
> I am not sure what causes this. I've heard more people complain
> about these features. It doesn't happen here. It might be a 
> architectural feature of the mudos driver. Are your unning v21.6 or
> above ?   
> 
> If so, what are your options.h (or local_options)
> 
> Leto

Bog, this does not sound like a driver problem at all.  If variables
ever lost their state, then none of us would use mudOS.  If you're 
going to look for the problem, save yourself a looot of time, and 
start looking in the lib =)
","id":96,]),(["title":"Re: MASTER_ONLY","poster":"Farrow","time":819302916,"body":"On Mon Dec 18, Leto wrote:
> On Mon Dec 18, Farrow wrote:
> > What gives user.c access to change MASTER_ONLY stuff?  I want to make
> > a stat file that will change stats, but I don't want to make the stats
> > PUBLIC access.  What do I have to do here?  I noticed that user.c doesn't
> > have ROOT_UID (obviously) *grin* so why does it work?
> > 
> > Farrow@Lost Worlds
> 
> At Earth we solved this by making a stat daemon. Objects can then call
> the daemon, and the daemon (running with root) can decide wether or not
> to actually execute the request.
> It also logs stat changes to /log/adm, so we can see if a player
> suddenly advances beyond the physical limits in a few hours
> (Eg: abusing a bug, or a wiz interfering :)
> 
> Leto
Is there a way I could check so that only certain files can call it?  I mean
give the file an id that only it can have?  Still not familiar with all the
security stuff, but I know my statd can be called by anything right now, and
that I don't like.  Well any suggestions would be appreciated.

Farrow
","id":97,]),(["id":98,"body":"On Mon Dec 18, Farrow wrote:
> What gives user.c access to change MASTER_ONLY stuff?  I want to make
> a stat file that will change stats, but I don't want to make the stats
> PUBLIC access.  What do I have to do here?  I noticed that user.c doesn't
> have ROOT_UID (obviously) *grin* so why does it work?
> 
> Farrow@Lost Worlds

MASTER_ONLY can be set if geteuid(previous_object()) == geteuid()
","time":819320577,"poster":"Hanzou","title":"Re: MASTER_ONLY",]),(["title":"loss of data","poster":"Dino","time":819329806,"body":"Found a new thing about the loss of data i experienced..

Once in a while when a command wont work, all i have to do is
update it to make it work.. if that helps, i'm clueless..;/

// Dino@Luvigana
","id":99,]),(["title":"Re:rust","poster":"Leto","time":819332379,"body":"I wasn't blaming the mudos driver. I was blaming the people who
run a mudlib that is designed for drivers of v21.6 or above, and
use an 'old' driver. Also, having the wrong options regarding uids
can be nasty :)

I was blaming the combination :)

Besides, it's known that MudOS has been tweaked a few times because
tmi muds found out about a bug while non-uid muds didn't have 
a problem.

Leto
","id":100,]),(["title":"Re: MASTER_ONLY","poster":"Dm","time":819333619,"body":"On Mon Dec 18, Farrow wrote:
> On Mon Dec 18, Leto wrote:
> > On Mon Dec 18, Farrow wrote:
> > > What gives user.c access to change MASTER_ONLY stuff?  I want to make
> > > a stat file that will change stats, but I don't want to make the stats
> > > PUBLIC access.  What do I have to do here?  I noticed that user.c doesn't
> > > have ROOT_UID (obviously) *grin* so why does it work?
> > > 
> > > Farrow@Lost Worlds
> > 
> > At Earth we solved this by making a stat daemon. Objects can then call
> > the daemon, and the daemon (running with root) can decide wether or not
> > to actually execute the request.
> > It also logs stat changes to /log/adm, so we can see if a player
> > suddenly advances beyond the physical limits in a few hours
> > (Eg: abusing a bug, or a wiz interfering :)
> > 
> > Leto
> Is there a way I could check so that only certain files can call it?  I mean
> give the file an id that only it can have?  Still not familiar with all the
> security stuff, but I know my statd can be called by anything right now, and
> that I don't like.  Well any suggestions would be appreciated.
> 
> Farrow

Take a look at the check in /adm/daemons/aproposd.c for making a check for
the calling file. (There's probably an easier example, but I was just playing
with this code yesterday and saw it.) :-)

Dm
","id":101,]),(["id":102,"body":"On Tue Dec 19, Leto wrote:
> I wasn't blaming the mudos driver. I was blaming the people who
> run a mudlib that is designed for drivers of v21.6 or above, and
> use an 'old' driver. Also, having the wrong options regarding uids
> can be nasty :)
> 
> I was blaming the combination :)
> 
> Besides, it's known that MudOS has been tweaked a few times because
> tmi muds found out about a bug while non-uid muds didn't have 
> a problem.
> 
> Leto

It still boggles me that TMI is running uids, when secure security systems
do exist, and have for almost 2 years now...

Also, why don't you do like LIMA does, and have the master check the
configuration via the get_config_str() function???

It'd save a lot of probs for you.

Rust
","time":819358394,"poster":"Rust","title":"Re: Re:rust",]),(["title":"restore_body","poster":"Farrow","time":819417688,"body":"Why is it that whenever restore_body is used things like auto_load
mappings aren't saved?

Farrow@Lost Worlds
","id":103,]),(["title":"Re: Re:rust","poster":"Leto","time":819418742,"body":"> It still boggles me that TMI is running uids, when secure security systems
> do exist, and have for almost 2 years now...

Well. Basically because these are all just bugfixes for now, because
the old admins decided to quit. 
As a personal reason, I find that the new system has the same effect
as firewalls. People get careless and make mistakes regarding
security. Things like calling quit() directly on a user had been
fixed here for years ago too, yet in was still in LIMA libs (and
Foundation/NM libs) until at least a few weeks back.
But, the first argument is obviously the more important one :)

> Also, why don't you do like LIMA does, and have the master check the
> configuration via the get_config_str() function???

That's a good idea. I made a config command a while ago to just
dump me the config file stuff (So I could login to new tmi mudlibs
and see if they had the right drvier if they were having problems)
but having a check in master at bootup is a good idea. I'll see
about getting that in soonish (Don't you love xmas breaks :)

Leto
","id":104,]),(["id":105,"body":"Here are two \"common\" cases where data loss can occur:

1) Some daemons use:
	inherit DAEMON;

   instead of:
	inherit SERVER;

   The difference is in how they handle the periodic clean up apply from the
   driver, and thus, affects how long they keep their data in memory over a
   long uptime.

2) Some people forget to use copy() when passing around sensitive data
   around, ie shared data structures such as arrays and mappings.  It
   doesn't take much to blow one away.

If you have a command that needs to be updated in order for it to work again,
make sure it is inheriting DAEMON, so that it is being cleaned up
after each use.

And considering that Dino seems comfortable hacking his lib, we should blame
the lib before the driver.  Not that I haven't seen my share of driver bugs...
>=)
","time":819432337,"poster":"Robocoder","title":"re: Loss of data",]),(["title":"Re: Re:rust","poster":"Rust","time":819529753,"body":"> As a personal reason, I find that the new system has the same effect
> as firewalls. People get careless and make mistakes regarding
> security. Things like calling quit() directly on a user had been
> fixed here for years ago too, yet in was still in LIMA libs (and
> Foundation/NM libs) until at least a few weeks back.
> But, the first argument is obviously the more important one :)

You are confusing the security of your mud with the security of your users.
Unless an admin writes a very poorly thought out call to unguarded(), you're
probably not going to be able to get access to files you shouldn't have
access to on Lima.  While you can use the same security for validating
function calls, it is usually overkill.  Being able to call quit()
in someone is not a security risk, it is only annoying. I don't 
prioritize something like that, because in practice on real muds,
wizards don't do annoying things like that unless they expect to get deleted
for it, or they have a good cause.  Also, using a strict security on less
than important calls like quit() could end up being a performance
hit if you use it liberally.  Security checks are usually pretty expensive,
and can really bump up your usage.  Look at set() and query() here...
They have so much security, and are used so often that they
really bring you a large performance hit that most muds just
don't suffer.

John
","id":106,]),(["id":107,"body":"This discussion is getting interesting indeed :)

You make a difference between wizards hacking file access and wizards
doing 'minor nasty things like calling quit()'. I am not so sure
if there is a difference. I can agree if you'd say soething like 'you
have to trust your wizards', but i don't see so much difference
in trusting them with files they shouldn't mess with, or functions
they shouldn't mess with. 
Most mudos muds are small and I agree that nasty wizzes are found
easily and terminated :) However, if you have a large mud you just
don't KNOW all your wizards (ofcourse others know them).
That's the reaosn why (again personally) I make sure that no wiz can
call anything they shouldn't. Especially true for player stats, and
other nasty things like quit etc.

But I agree if gives quite some overhead, and will cause the mud to
be slower (especially when using query/set :) :)

Leto
","time":819639197,"poster":"Leto","title":"Re:Rust",]),(["title":"Re: Re:Rust","poster":"Rust","time":819654856,"body":"On Fri Dec 22, Leto wrote:
> have to trust your wizards', but i don't see so much difference
> in trusting them with files they shouldn't mess with, or functions
> they shouldn't mess with. 
Well, one compromises the security of your mud's file system, and
the other doesn't really have to at all.  Also, while I don't 
believe you have to be able to trust your wizards like they're your
mother, I do think its a nice gesture to give them a bit of your
trust.  What happens when someone logs a script on to your mud that spams
everyone?  Well, your wizard isn't going to have any recourse if
you're not around, if he can't dest players (or call quit in them).
What you want to stop is irresponsible use of your lib.  Responsible
use of it should be encouraged, and sometimes they involve the
same function calls.  It's also very difficult to change your policies
if you want to create some sort of position where you trust one of
your wizards to fix players stats when they abuse a bug, or whatever,
but you still don't want to give them admin access, when you are
securing everything on a per-function basis.

> Most mudos muds are small and I agree that nasty wizzes are found
> easily and terminated :) However, if you have a large mud you just
> don't KNOW all your wizards (ofcourse others know them).

I think the easy was around this is logging.  Then you can see who's
calling what you don't want them to call, and then go see if they
had a valid reason, if that concerns you.  Also, you can get away with a
very small speed penalty for logging, as opposed to using your security 

> 
> But I agree if gives quite some overhead, and will cause the mud to
> be slower (especially when using query/set :) :)
> 
> Leto
","id":109,]),(["title":"Re: Re:Rust","poster":"Leto","time":819657561,"body":"> Well, one compromises the security of your mud's file system, and
> the other doesn't really have to at all.  Also, while I don't 
> believe you have to be able to trust your wizards like they're your
> mother, I do think its a nice gesture to give them a bit of your

Well, function calls to dangerous things are just as bad as write access
to the wrong files. The one leads to the other.

> trust.  What happens when someone logs a script on to your mud that spams
> everyone?  Well, your wizard isn't going to have any recourse if
> you're not around, if he can't dest players (or call quit in them).

If no high enough wizard is online to fix it, they can try
to email the administrator so he might login sooner (as stated
in our help files at earth) or they'll have to suffer a bit.
The police isn't also everywhere all the time in RL either.
Sometimes, you'll have to live with your neighbours taste of
music :)

> What you want to stop is irresponsible use of your lib.  Responsible
> use of it should be encouraged, and sometimes they involve the
> same function calls.  It's also very difficult to change your policies
> if you want to create some sort of position where you trust one of
> your wizards to fix players stats when they abuse a bug, or whatever,
> but you still don't want to give them admin access, when you are
> securing everything on a per-function basis.

I guess that is true. Right now, on Earth, we're small enough
so that the three wizards with admin access can fix all that
needs fixing regarding players. However, that is easily changed
since we have a central stat_daemon which will grant permissions
to change player stats. So, we could write a new cmd that would
be placed in a directory corresponding with the level of wizard
we want to give access to player stats. (And add protection in 
that command ofcourse).

> I think the easy was around this is logging.  Then you can see who's
> calling what you don't want them to call, and then go see if they
> had a valid reason, if that concerns you.  Also, you can get away with a
> very small speed penalty for logging, as opposed to using your security 

We do both. The above mentioned stat daemon also logs all stat changes.
If a player rises from the lowliest to the highest in an unreasonable
amount of time. We'll know it :)

Leto
","id":110,]),(["title":"Re: Re:Rust","poster":"Rust","time":819658918,"body":"> Well, function calls to dangerous things are just as bad as write access
> to the wrong files. The one leads to the other.

Not true at all, al least with Lima's security.  I don't have to add
any extra security to a function that does a write_file.  If you
call that function, the security system won't allow it because it
has to do with file access.  You can't defeat the security system
just by calling functions that do file access.
> 
> If no high enough wizard is online to fix it, they can try
> to email the administrator so he might login sooner (as stated
> in our help files at earth) or they'll have to suffer a bit.
> The police isn't also everywhere all the time in RL either.
> Sometimes, you'll have to live with your neighbours taste of
> music :)
I am of the oppinion that anything you can do to ease your wizards
and players (the ones you want to keep at least) suffering is a good thing.
If you're not compromising the security of your mud, and if you can
tell when someone is abusing your system, why not give them some
flexibility as long as they are using it responsibly?
> 
Rust
","id":111,]),})
id_ref 123