#d/TMI/boards/driverboard.c
ob_data (["last_location":0,"id":({"board","bulletin board",}),"silent_look":1,"long.text":"This is a bulletin board. For information on how to use it, use `help board'.
","short.text":"The MudOS driver board","long":"@@query_long","short":"@@query_short",])
messages ({(["title":"Re: MudoS on Windows95","poster":"Avatar","time":827767122,"body":"On Mon Mar 25, Lucas wrote:
> Is there a chance that a MudOS version could ever run on windows95?
> -lucas-
> PS: meaning that you couldhave a mud setup on windows95
Should be... IMHO: not much difference between early NT (3.5) and w95 (except
that w95 should be a bit more stable and the gui).
Examine driver/windows, which contains information about getting it running.
","id":21,]),(["title":"Re: MudoS on Windows95","poster":"Avatar","time":827767152,"body":"On Mon Mar 25, Moksha wrote:
> On Mon Mar 25, Lucas wrote:
> > Is there a chance that a MudOS version could ever run on windows95?
> > -lucas-
> > PS: meaning that you couldhave a mud setup on windows95
>
> Although I see that making sense with how many people run Windows95 I find
> the whole idea of a MU*/Windows95 combo to be nauseating. *gag*
>
> Sorry, I think Bill Gates is an amazing guy but I hate Windows.
>
> - Mk
I hate W95, but I do lik windows NT :P
","id":22,]),(["title":"Re: MudoS on Windows95","poster":"Hanzou","time":827769470,"body":"On Mon Mar 25, Lucas wrote:
> Is there a chance that a MudOS version could ever run on windows95?
> -lucas-
> PS: meaning that you couldhave a mud setup on windows95
there is a total of 2 checks for a WIN95 define in the entire code
rumor says this stuff isn't finished yet
","id":23,]),(["title":"Win95 and MudOS","poster":"Farrow","time":827799018,"body":"I know someone that tried to compile it for Win95 using gcc for Win95 and
he ended up crashing it so bad he had to reinstall. First off when is Billy
going to catch up with Intel. I hope to god Intel's P6 isn't hurt by the
lack of 32 bit code in Win95. Personally I stick with Linux for anything
that I can. Everything else of mine is either Dos based or 3.1 based. I
don't like Windows. NT is slow. I find GUI's to be a pain anyway. They are
all buggy.
Farrow
","id":24,]),(["title":"Win95","poster":"Lucas","time":827803532,"body":"Okay. I would MUCH rather use Linux, but it's a family computer and
nobody else could figure it out.
If there is a way to install Linux on the same hard drive as Win95,
that'd be great. I just don't know how.
-lucas-
","id":25,]),(["title":"Re: Win95","poster":"Dalto","time":827806973,"body":"On Tue Mar 26, Lucas wrote:
> Okay. I would MUCH rather use Linux, but it's a family computer and
> nobody else could figure it out.
>
> If there is a way to install Linux on the same hard drive as Win95,
> that'd be great. I just don't know how.
> -lucas-
It is possible to install Linux on the same hard drive but you would have to
repartition it which would delete all the data on it.
-Dalto
","id":26,]),(["title":"Re: Win95","poster":"Moksha","time":827807295,"body":"On Tue Mar 26, Dalto wrote:
> On Tue Mar 26, Lucas wrote:
> > Okay. I would MUCH rather use Linux, but it's a family computer and
> > nobody else could figure it out.
> >
> > If there is a way to install Linux on the same hard drive as Win95,
> > that'd be great. I just don't know how.
> > -lucas-
> It is possible to install Linux on the same hard drive but you would have to
> repartition it which would delete all the data on it.
> -Dalto
You would also need to have a rather good sized HD to hold everything you
would want to do. But, heh, if you have it then go for it ;)
- Mk
","id":27,]),(["title":"Re: MudoS on Windows95","poster":"Rust","time":827860277,"body":"On Mon Mar 25, Lucas wrote:
> Is there a chance that a MudOS version could ever run on windows95?
> -lucas-
> PS: meaning that you couldhave a mud setup on windows95
Yes, there is a beta version of mudOS for windows 95. Right now, you
need to use Visual C++ to compile it. The instructions are somewhere
in all the driver source.
","id":28,]),(["title":"Re: Win95","poster":"Farrow","time":827900976,"body":"On Tue Mar 26, Dalto wrote:
> On Tue Mar 26, Lucas wrote:
> > Okay. I would MUCH rather use Linux, but it's a family computer and
> > nobody else could figure it out.
> >
> > If there is a way to install Linux on the same hard drive as Win95,
> > that'd be great. I just don't know how.
> > -lucas-
> It is possible to install Linux on the same hard drive but you would have to
> repartition it which would delete all the data on it.
> -Dalto
Nah, not if your good. You can split the partitions up using FIPS. It's
very easy to do if you follow the instructions. I don't suggest installing
Linux unless you absolutely know what you are doing though. A lot can go
wrong and you can totally mess things up.
Farrow
","id":29,]),(["id":30,"body":"On Wed Feb 28, Leto wrote:
> On Tue Feb 27, Hanzou wrote:
>
> > Recompile the driver with PACKAGE_UIDS defined and MUDLIB_ERROR_HANDLER
> > undefined.
>
> Euh, you definetly want MUDLIB_ERROR_HANDLER defined !!
>
> Leto
In the driver source it mentions security holes with this option, is this known
and dealt with the TMI-2, or is it a \"we dont care\" situation?
Thanks!
-Crity
","time":828312850,"poster":"Crity","title":"Re: Problem running with MudOS 21.7b16",]),(["id":33,"body":"On Sun Mar 31, Crity wrote:
> On Wed Feb 28, Leto wrote:
> > Euh, you definetly want MUDLIB_ERROR_HANDLER defined !!
> In the driver source it mentions security holes with this option, is this known
where in the driver source? i don't see any mention of that in options.h or
simulate.c
","time":828337776,"poster":"Hanzou","title":"Re: Problem running with MudOS 21.7b16",]),(["id":34,"body":"On Mon Apr 1, Hanzou wrote:
> On Sun Mar 31, Crity wrote:
> > On Wed Feb 28, Leto wrote:
> > > Euh, you definetly want MUDLIB_ERROR_HANDLER defined !!
>
> > In the driver source it mentions security holes with this option, is this known
>
> where in the driver source? i don't see any mention of that in options.h or
> simulate.c
From options.h in v22a25:
/****************************************************************************
* UID PACKAGE *
* ----------- *
* UIDS are the basis for some mudlib security systems. Basically, they're *
* preserved for backwards compatibility, as several ways of breaking *
* almost any system which relies on them are known. (No, it's not a flaw *
* of uids; only that b/c of the ease with which LPC objects can call *
* each other, it's far to easy to leave holes) *
* *
* If you don't care about security, the first option is probably what you *
* want. *
****************************************************************************/
","time":828344075,"poster":"Crity","title":"Re: Problem running with MudOS 21.7b16",]),(["id":36,"body":"Uids can be dangerous if used wrong. The same applies to netscape,
java, sh, sendmail, login, /dev/null and stack security.
If we find holes, we plug them. Notice that uids, as the package
tells you, are NOT buggy. We can just be sloppy with them (as you can
with almost anything that requires privs to run. Let's face it. How hard
can it be to write a decent save mailer, and why don't we have one yet?)
So far, we can and do protect anything that's worth protecting. Realize
though, that it is always a trade-off against performance.
Leto
Ps. Thjere is always one Golden rule that applies to all muds
\"If you can't trust your wizards, you're screwed\"
","time":828402886,"poster":"Leto","title":"Re:security holes",]),(["id":37,"body":"On Tue Apr 2, Leto wrote:
> Uids can be dangerous if used wrong. The same applies to netscape,
> java, sh, sendmail, login, /dev/null and stack security.
The difference here is that it is incredibly easy to use UIDs wrong.
_incredibly_ easy.
>
> If we find holes, we plug them. Notice that uids, as the package
> tells you, are NOT buggy. We can just be sloppy with them (as you can
> with almost anything that requires privs to run. Let's face it. How hard
This is really misleading of you. The way to make UIDs work is to
secure every function that might ever have a chance to be priv'd,
or make a priv'd call. This is essentially the entire mudlib.
The big advantage of the system on all the other major mudlibs right now
is that security holes can only be introduced at unguarded() calls.
There are only 34 such calls in the entire Lima mudlib, so a
careful person who knows the workings of the security system could
fairly quickly convince himself that the mudlib is secure.
On this lib, you just can't do that.
I remember 2 years ago when my second character was hacking
mobydick every other day to get rid of some of the security problems
of this lib, I put together a list of 5 or 6 problems that could
only be fixed by a complete rewrite of the security system...
Unfortunately, that was so long ago, and since we lost all of those
files, I don't have a firm enough memory of anything other than that
problems in TMI's security do exist.
It would be really daft to claim that TMI is secure, or even compare it to
things like Java, which at least make a structured attempt to achive security.
Rust
","time":828514058,"poster":"Rust","title":"Re: Re:security holes",]),(["id":41,"body":"incidentally, the last security hole in tmi-2 i saw that was major, i.e.
allowed a user to get admin access, had nothing to do with uids.
although yes, stack security would have been able to block it.
","time":828588424,"poster":"Hanzou","title":"re: re: re: security holes",]),(["id":42,"body":"On Thu Apr 4, Hanzou wrote:
> incidentally, the last security hole in tmi-2 i saw that was major, i.e.
> allowed a user to get admin access, had nothing to do with uids.
All security bugs are major :)
And people can stop telling my stacks ecurity is better. I know :)
But I also know makes people overconfident. It has the same effect
as a firewall in a large organisation.
Leto
","time":828661394,"poster":"Leto","title":"Re: re: re: re: security holes",]),(["id":43,"body":"On Fri Apr 5, Leto wrote:
> On Thu Apr 4, Hanzou wrote:
> > incidentally, the last security hole in tmi-2 i saw that was major, i.e.
> > allowed a user to get admin access, had nothing to do with uids.
>
> All security bugs are major :)
>
> And people can stop telling my stacks ecurity is better. I know :)
> But I also know makes people overconfident. It has the same effect
> as a firewall in a large organisation.
>
> Leto
Bah. Overconfidence is NOT backing up your mud specific stuff regularly.
I don't know many people that confident. All we're saying is that people
who place confidence in TMI's security system have much less of a reason
to be doing so... They only do so because YOU lead them to believe it is
as secure as Java or stack security...
Rust
","time":828666021,"poster":"Rust","title":"Re: re: re: re: security holes",]),(["id":44,"body":"On Wed Apr 3, Rust wrote:
> This is really misleading of you. The way to make UIDs work is to
> secure every function that might ever have a chance to be priv'd,
> or make a priv'd call. This is essentially the entire mudlib.
boggle. it's possible to have a stack security system using uids
","time":828672144,"poster":"Hanzou","title":"Re: Re:security holes",]),(["id":45,"body":"On Fri Apr 5, Hanzou wrote:
> On Wed Apr 3, Rust wrote:
> > This is really misleading of you. The way to make UIDs work is to
> > secure every function that might ever have a chance to be priv'd,
> > or make a priv'd call. This is essentially the entire mudlib.
>
> boggle. it's possible to have a stack security system using uids
Duh.
I was talking about the way TMI uses them, which we're refering to
as UID security because every mud that uses UIDS uses them in this
way. No one implements stack security w/ UIDS as it would
be more expensive than necessary, and would be a bit harder to
completely secure.
","time":828724854,"poster":"Rust","title":"Re: Re:security holes",]),})
id_ref 55
