#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