Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!rti!xyzzy!meissner
From: meissner@xyzzy.UUCP (Michael Meissner)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: core dumps life-after-death
Message-ID: <137@xyzzy.UUCP>
Date: Thu, 16-Jul-87 10:16:30 EDT
Article-I.D.: xyzzy.137
Posted: Thu Jul 16 10:16:30 1987
Date-Received: Sat, 18-Jul-87 07:12:56 EDT
References: <276@frc.UUCP>
Reply-To: meissner@nightmare.UUCP (Michael Meissner)
Distribution: comp
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 29
Xref: mnetor comp.unix.questions:3217 comp.unix.wizards:3267

From article <276@frc.UUCP>:
> 		/* stuff about using dbx on core dumps */
> 	I imagine there are problems with open files,
> file positions, and other "kernel" type information.
> Can a process get all this "stuff" as it dies. And 
> do the tools to recreate the "old" environment already
> exist?
> 
> 	Can core Images be used to checkpoint large jobs?

In short this is not a good idea.  If you were to include "ALL" of the
information about the process state, it would envitably have to include
the effective user-ID and group-ID of the process.  If this were included
in the file, users could then get around what protections UNIX does offer
by checkpointing a job, and then using something like adb to change the
user/group to some other user.  I remember when I was an undergrad at the
University of Minnesota ten years ago, that the operations staff removed
the checkpoint facility from the CDC 6400 because of this problem.

Even if it were possible to make such a system secure, there are still
many loose ends.  For example if you restore a process, do you have to
repaint the screen at the time of the dump, open up socket connections
to servers (which might not have the same process ID), and in fact restart
the server with the same state.  Ditto for pipes, terminal controls, etc.

If you really need to checkpoint large jobs, I would suggest that it be
up to the application.  Bare in mind, that attempts to unexec a process
like GNU does, quickly becomes implementation dependent (ie, non-portable).
-- 
Michael Meissner, Data General.		Uucp: ...!mcnc!rti!xyzzy!meissner