Re: Sorry about where can I get this MUD.

From: Daniel Staudt (
Date: 02/21/00

on my mud security of 'big' itemes is mainly direct IDNUM checks.
anyways i'm more interested on how you would go about making a subshell in
the mud that could access the rest of the computer includeing perl.  i have
tried to use perl in c/c++ before and never could get any where with it.

>From: Peter Ajamian <peter@PAJAMIAN.DHS.ORG>
>Reply-To: Circle Discussion List <>
>Subject: Re: [CIRCLE] Sorry about where can I get this MUD.
>Date: Sat, 19 Feb 2000 02:40:33 -0800
>Patrick Dughi wrote:
> >
> > > Hrmmm, an interesting idea might be to set up your own login and
> > > restricted shell inside the shell you are given, a moderate amount of
> > > perl scripting would probably be needed for this and you could assign
> > > all your programers user names and maintain a database with encrypted
> > > passwords, then they have to do a double-login, first they telnet (or
> > > ssh) to the shell account and then the .bash_profile will launch a
> > > secondary login/authentication with thier assigned username/passwd
> > > then gives them access to a restricted shell that you control, you can
> > > maintain filelists for each programmer to only allow them access to
> > > ceartain files, and do a host of other things to limit them
> > > appropriately (use your imagination).  You set it up so that you and
> > > your most trusted programmers will have access to the full shell also.
> >
> >         This is a good idea; my first on this thread actually, but I
> > discounted it because of the lack of good control allowed.  You could
> > start at the same problems net providers experience when they change
> > someone's login shell from a valid one to '/bin/false'.  They still have
> > access, and if they're tenacioius, usually they can still use the
> > account/change it back.  Trying to give them partial access would be
> > scary.
> >
>There is a security risk for any kind of access you give someone,
>however, I think it is safe to say that allowing a programmer full shell
>access is less secure than allowing access to a restricted shell.  There
>will always be holes, but by restricting a programmer's access you are
>adding one more deterrent, and if you make it difficult enough for
>someone to break they may decide that it is simply easier to write thier
>own code than to gain access to yours.
> > >
> > > Another possibility would be to set it up to allow a limited amount of
> > > programming from within the MUD itself, you could use a modified form
> > > the tedit and file (patch/snippet?) along with copyover and then write
> > > simple command to run ./configure and make from inside the MUD.
> > >
> >         Good idea, but same problems.  Though I did want to have it so I
> > could shell out from within the mud, it was for reasons other than
> > security.  I was just curious how much could be done using the mud as an
> > access control + log generator.  It'd be nice for management reasons.
>Well, I do have to admit that this one poses ceartain greater security
>risks, when you open up a method to allow access to from within the MUD,
>then any player has the potential of finding and exploiting a hole which
>gives them that access or a subset of it.  This method is, therefore,
>more of a conveniance than for security and anytime you increase
>conveniance in a manner such as this you decrease your security as a
>result.  It is a give and take as any conveniance on the internet is.
>Regards, Peter

Daniel Staudt <>
I'm out of my mind, but feel free to leave a message.
ICQ UIN# <14148959>

Get Your Private, Free Email at

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT