Re: Was: Rare Bug Now: Dumping Cores

From: Patrick Dughi (
Date: 10/09/01

> >> I know that the MUD can dump core files, but mine does not, perhaps I
> could > >Anyhow, if you type "ulimit -a" you'll get maybe something
> like:  >core file size (blocks)  0 >"ulimit -c unlimited", which'll
> result in:  >core file size (blocks)  unlimited
> Or set it w/in the program itself.
> (-- mailer code --)
> somewhere early in the initialization of everything:
> struct rlimit rlim;
> rlim.rlim_max = RLIM_INFINITY;
> if(setrlimit(RLIMIT_CORE, &rlim)) {
>         sprintf(errbuf, "SYSERR: Error setting core limit '%m');
>         basic_mud_log(errbuf);
> } else
>         basic_mud_log("Core size set.");
> I have a little function called void limits(void) called which does
> that, makes sure the mud is running setgid as group mud, makes sure it's
> chdir'ed to the right place, and a couple other little things like that.

        Woohoo! Let's crack his machine via the mud!  He's given the
process superuser privledges! Huzzah! :)

        Seriously people, this isn't the right way to do it.

        There's a few things you can do that are less blatenly insecure;
if you're the administrator of the machine you're on and you're getting
limit problems, examine the common rc scripts (like /etc/cshrc or
/etc/bashrc, etc.... depending on which shell you're logging in with).  If
they lower the limit at all, it cannot be raised without superuser
privledges (so remove those lines!).  Then, check the local (mud user's)
account for simliar files (.bashrc, etc, in their home dir).

        Now, once I even had to go into the kernel and change the default
settings for RLIMs, but frankly even that was easy, it's stored in an
array somewhere, took 5 minutes of hunting to locate it.

        If, for some godforsaken reason you really REALLY have to use
setrlimit, immediately after, setuid & setgid to something reasonable.
Like an account specifically made to run insecure apps which can be easily
crashed by user input.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST