From: <ed_heinrich@npd.novell.com>
Newsgroups: vmsnet.internals
Subject: Re: Help getting image dumps?
Date: Mon, 13 Apr 92 9:24:07 MDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


In article <1992Apr11.075127.11757@infocomm.com>,
 <mark@infocomm.com> writes:

>In article <9204071514.AA17947@ithaca.Eng.Sandy.Novell.COM>,
> <ed_heinrich@npd.novell.com> writes:
>>         Years ago I worked for a company with sites throughout the world and
>> we had the requirement to have a dump file to examine back in the development
>> office.  The following are the extracted relevant pieces that I used in an
>> exception handler to cause an image dump file.  It also has the feature of
>> purging the dump file to prevent exhausting the customers disk space.
>>
>>
>>         It has been a while since I looked into the conditions that allow/
>> disallow RUN/DUMP from creating a dump file but I got around those checks
>> by calling the image dump merge routine directly.  This approach allows a
>> dump to be generated no matter what RUN command is used.
>>
>>         After the exception handler had written out messages to a disk file
>> and the system console, it would set the PHD$M_IMGDMP bit in the PHD and then
>> call the EXE$IMGDMP_MERGE code to merge in the image dump facility and
>> execute it.  This assumes that the code thread is executing in user mode and
>> that the process has CMKRNL privileges.  (Actually the real version called a
>> user-written service to set the PHD bit so that the process did not need
>> CMKRNL privs).  This approach gets around the requirement that a process be
>> RUN/DUMP.  It worked very well for us.

>This stuff looked great, but I've noticed the following:
>
>      - The CMKRNL priv really isn't needed since a user process can merely do
>        a $ SET PROCESS/DUMP to turn on the PHD$M_IMGDMP bit without any extra
>        privs.

That is TRUE, if you can insure that the image is either RUN/DUMP or a $SET
PROCESS/DUMP is done prior to image activation.  However, the code was
designed to INSURE a dump was taken no matter how the process was started.

In the normal environment, we had one process that issued $CREPRC calls to
create a bunch of other processes as DETACHED processes when the system
started up.  We might, however, have someone running another process at
the terminal.  This was originally written in 1986 and I know RUN/DUMP
existed, but I really don't remember how much support there was at the time,
or even today as I haven't worked on that system in three years, for doing
a SET PROCESS/DUMP equilivant in code to insure the process had the
PDH$M_IMGDMP bit set.  (I didn't look at the code, but I suspect that the
SET PROCESS/DUMP simply sets the PHD bit since the image dump merge code
uses that bit as a determining factor for allowing adump to occur). Certainly
if the environment requires the use of a .COM file for execution, there would
be no need to require CMKRNL privilege as the .COM file could issue the
$ SET PROCESS/DUMP DCL command before executing the image.


>      - The automatic purging of the old dump files is great!

Thanks! After a particular program was modified, it started dumping about
twice a day and one day a customer ran out of disk space, so it became a
requirement.  Since this was a production system that went for weeks at a
time before it was restarted, we could not just purge the files at startup
time.  One of the other nice things we did was to declare the condition handler
in every program as part of an common initialization macro.  If the condition
handler was executed, it unwound the stack and allowed the image to "restart"
as if it had been re-run.  Since many of the processes were detached, this
eliminated the need for a watch-dog mechanism to detect when a process
terminated.  We did have a watch-dog, a termination mailbox via the $CREPRC
system service, but it was only used for a couple of ill-behaved processes
that could not recover gracefully.


>      - The code (when executed from User Mode anyway), ONLY ends up producing
>        a dump if the image that is being run is NOT installed with privs.
>
>I remember something about a security hole related to ANAL/PROCESS_DUMP and
>images installed with privs.  The first work around to this problem was to
>protect ANAL/PROCESS_DUMP (SYS$SYSTEM:ANALIMDMP.EXE) so users couldn't run it
>(OR to NOT install it with privs), I don't remember the detail.  In any case it
>seems that the eventual fix was to make sure that installed images NEVER have
>process dumps taken, and hence avoid the problem entirely.

Yes, that is correct.  There was a rather NASTY bug that, although it took a
little imagination to think of, would allow access to privileges that an image
was installed with. Part of the fix was not to allow dump files if the image
is installed w/ privileges.  When I posted this, I had forgotten about that
caveat, thanks for reminding us!


>--
>Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
>PHONE:  (415)369-9366   UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
>DOMAIN: mark@infocomm.com

-------------------------------------------------------------------------------
Ed Heinrich, Novell, Inc.       Sandy, Utah
ed_heinrich@npd.Novell.COM

                "it's NOT the kill, it's the thrill of the chase"
-------------------------------------------------------------------------------