[3016] in testers
8.0C sparc: Not taking dumps by default a mistake
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Jul 21 01:28:15 1996
Date: Sun, 21 Jul 1996 01:28:07 -0400
To: testers@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
After tonight's experience w/ portnoy's crash, I think it's a mistake
for Athena workstations (including public ones) not to be configured
to save core images by default.
In particular, I wonder how many similar crashes have occured that
people have ignored or not known what to deal with, or will occur. A
cursory inspection of the dslogger discuss meeting shows that very few
have paniced under 2.3; pessimistically I think things will worsen
under 2.4 (8.0).
Certainly we need to avoid the SGI problem of filling up the disk, but
assuming Sun's savecore isn't broken like SGIs, this could be
accompished with the appropriate setting of "minfree".
It would also be reasonable to have a cron job remove week-old dumps;
essentially I'd like to ensure that the most recent dump on a given
workstation is available, if possible.
On the other hand, I guess it's important to point out that there's
an significant security issue here. I don't think anyone brought it
up when the SGIs were configured to core dump, and I assume that's
an oversight (certainly, *I* didn't think of it at the time...);
viz., a core dump while the system had an active user is not unlikely
to contain passwords and/or tickets which could extracted with
a lot of pain by a truely determined individual.
One could imagine all sorts of schemes to address this, like having a
server somewhere devoted to collecting these dumps (jason? :-)) and
either using a version of savecore that blits the dump out on the
network, or modifying the boot process to copy the dump out of
/var/crash (to this server) and then delete it. Of course, ideally,
such a process should be secure, which would require public key
cryptography (it would be trivial to use ssh (in the form of scp) to
do this, however). Another possibility would be to extract important
bits of information from the dump (ideally taking up much less space than
the dump itself), such as the stack trace and some tables and state,
communicate that somewhere (email?), and then remove the dump.
I hope the overhead and potential security issues of crash dumps
don't cause them to be ignored, since they can provide very useful
information about potentially serious problems.
--jhawk
