topic Recall Command in Operating System - OpenVMS

Recall Command

Zeni B. Schleter — Mon, 19 Dec 2005 10:05:58 GMT

OpenVMS 7.3-2

Is there a way to do "Recall/Output=file.ext" from a command procedure?

I checked the manual and it refers to terminal buffer only but perhaps there is a way to redirect the buffer within a command procedure.

*note- I had earlier posted this on the wrong forum .

Re: Recall Command

Ian Miller. — Mon, 19 Dec 2005 10:42:44 GMT

The recall buffer remembers commands entered at a terminal not anything from a command procedure. What are you trying to achive?

Re: Recall Command

Volker Halle — Mon, 19 Dec 2005 10:59:11 GMT

Zeni,

you can view the command recall buffer with SDA:

$ SET PROC/PRIV=CMK
$ ANAL/SYS
CLUE PROCESS/RECALL
EXIT

For a sufficiently privileged user, these commands can be executed in a DCL procedure.

The RECALL commands only work if you are at the DCL prompt, not from within a DCL procedure.

Volker.

Re: Recall Command

Zeni B. Schleter — Mon, 19 Dec 2005 11:03:14 GMT

I am trying to collect commands issued for a privileged interactive session.

I have set up the LOGGER utility from the freeware link. It works but capturing the command stream would take less space.

Bullet-proof is not part of the requirement. Privileged users by definition have privileged access.

Re: Recall Command

Heinz W Genhart — Mon, 19 Dec 2005 11:15:41 GMT

Hi

You can do the following:

$ define sys$output tempfile.tmp
$ recall/all
$ deassign sys$output

You will find all previous entered commands in tempfile.tmp

Regards

Heinz

Re: Recall Command

Zeni B. Schleter — Mon, 19 Dec 2005 11:17:12 GMT

The Clue Process works for OpenVMS 7.3-2 but I have some VAX at v7.1.

Re: Recall Command

Zeni B. Schleter — Mon, 19 Dec 2005 11:22:45 GMT

Heinz,
Trying to redirect the output did not work on either VMS 7.1 nor VMS 7.3-2

Re: Recall Command

Zeni B. Schleter — Mon, 19 Dec 2005 11:38:56 GMT

Volker,
The Analy/Sys will work well for the newer systems. That will help a lot. Thanks.
The logger routine will work for the older systems. Since there is less activity on those, that should be livable.
Thanks to all for input.

Re: Recall Command

Volker Halle — Mon, 19 Dec 2005 11:45:13 GMT

Zeni,

you dind't say you wanted to do this on VAX as well ;-)

See the following article for how to do this on a VAX. There are no CLUE$SDA extensions for OpenVMS VAX.

http://h18000.www1.hp.com/support/asktima/operating_systems/00947357-25899660-1C01E7.html

Volker.

Re: Recall Command

Hein van den Heuvel — Mon, 19 Dec 2005 11:54:24 GMT

fyi,

RECALL/ALL explicitly protects against writing to an output file when in batch mode. They (Dave M) designed it that way in order to protect against malicious batch jobs 'scraping' the command stream for passwords. I always thought this was a poorly exectued idea as it is obviously very handy to be able to save teh recall automatically when you logout. But this is the way it is (unfortunately) designed to work and how it will stay working.

There is code (freeware) out there that can help with this problem. There are even DCL prodecures that dive into DCL data space to extract the old commands. Google and yeah shall find.

Cheers,
Hein.

Re: Recall Command

Robert_Boyd — Mon, 19 Dec 2005 13:40:09 GMT

Hein,

Can you say some more about this idea of batch jobs (or is it reallly command procedures?) "scraping" the DCL buffer ?

I have wanted from the day that RECALL/OUTPUT came out to be able to have a logout command that would capture my command stream and let me reload it when I log back in.

The closest I ever came to this was setting up keypad commands to implement the RECALL/OUTPUT command. The problem with that is that it's just too much effort to remember to do it every time consistently, and it doesn't help when I'm logged in from a session where I don't have the luxury of a DEC compatible keypad/emulation readily accessible.

I'm curious about this malicious code idea -- if someone's already compromised the system enough to be able to put something like that into play, you're probably in deep trouble.

Robert

Re: Recall Command

John Gillings — Mon, 19 Dec 2005 16:51:17 GMT

>Can you say some more about this idea
>of batch jobs (or is it reallly command
>procedures?) "scraping" the DCL buffer ?

It's command procedures...

File name syntax includes the optional "access control string" for network file specifications:

node"username password"::dev:[dir]file.typ

So, suppose I type the command:

$ TYPE REM"SYSTEM SECRET"::DKA0:[HOME]MYFILE.DAT

to display a file on node REM, then sometime later I execute YOUR (trojan) command procedure "HANDY.COM"

Now, your procedure could RECALL/OUT *MY* recall buffer, parse the contents, and discover the triplet of node name, username and password.

For this and a few other reasons, the RECALL command is ignored from any command procedure. Think about it, what would a non-interactive RECALL command mean? Also, RECALL/IN could be used to plant trojan commands in the recall buffer of an unsuspecting user.

From a suitably privileged process, using SDA, the recall buffer can be determined for any process, from any version of OpenVMS, (VAX or Alpha), the CLUE PROCESS just makes it easier from V7.3-2.

Create a file:
$ CREATE RECALL.SDA
define prcbase = @(ctl$ag_clidata+ppd$q_clireg+4)
examine prcbase+prc_g_commands;400
examine prcbase+prc_l_recallptr

SDA:
SDA> READ SYS$SYSTEM:DCLDEF
SDA> @RECALL.SDA

(you'll have to work out where the commands start and stop yourself)

Re: Recall Command

John Gillings — Mon, 19 Dec 2005 16:56:40 GMT

Oops, forgot...

From Alpha it's

SDA> READ SYS$LOADABLE_IMAGES:DCLDEF

you will also have to increase the examine size from ";400"

Re: Recall Command

Hein van den Heuvel — Mon, 19 Dec 2005 17:20:26 GMT

Oops, don't know what made me write batch job. I meant command file as John suggested.
Supposedly you could be tricked into using a longish non-transparent command file which normally say gives you a build environment, but on special days or times peaks into you command buffer for usefull usename/passwords. Like Robert writes I believe that you have bigger problems than allowing recall/out in a command file if you had such trap on the box.
And like Robert I have wished to be able to do a simple build-in recovery of my last session, oh what a thousand times, and I have use a command line with embedded password maybe 5 times.
Anyway, for the actual problem Zeni tries to solve it does not seem enough to stick this in a command file to be executed say at logout. I'd sooner opt for random samples with SDA or a privved tool made for the purpose, or good old auditing.

I like Zeni observation that it needs not be perfect because he will be dealing with privved users anyway.

Hein.

Re: Recall Command

Kris Clippeleyr — Tue, 20 Dec 2005 02:49:00 GMT

Zeni,
In the days when comp.os.vms still contained real gems of freeware, I got my hands on the sources of the RETRIEVE program by Jo Torsmyr from Norway.
Before the extension of RECALL beyond the last 20 commands, I used this utility instead. It behaves similar to the RECALL command as we know it today, and has also the possibility of storing/retrieving the commands in/from a file.
The last time I used & tested it was on VAX/VMS V5.4, so no guarantees.
Btw, you'll need a Pascal compiler to build this thing.
Good luck,
Kris (aka Qkcl)

Re: Recall Command

Ian Miller. — Tue, 20 Dec 2005 05:55:49 GMT

I think that program will need some work due to DCL internal changes (EDCL project and more commands in the history).

Re: Recall Command

Ian Miller. — Tue, 20 Dec 2005 06:55:38 GMT

The original requirement appears to obtain a record of what a privileged user did.

Parhaps using the LOGGER program or similar may be the best way forward.

What is the reason for the record?

Re: Recall Command

Zeni B. Schleter — Tue, 20 Dec 2005 08:51:45 GMT

Good discussion. It will take me a bit to catch up with points but I will.
Reason for this effort is a security requirement. The constraint is that it has to be applicable to multiple platforms.
A by-product that will probably be more useful than the original intent will be that we can go back and review when we encounter such moments as "What did I do that caused that?" Usually encountered after reboots.
What is requested sounds a lot like the complete monitoring done by a VaxCluster console software for the OPA0 port. Time, Money, and effort is not on our side for that.

Re: Recall Command

Robert_Boyd — Tue, 20 Dec 2005 10:27:09 GMT

Zeni,

If you did have money and time and effort available there are some excellent products available such as ConsoleWorks, or Console Manager. I worked for about 9 years with Console Manager and I've also done some consulting on a pilot project for an installation of ConsoleWorks.

A procedural solution that is very inexpensive is something that I often do when such a product is not available. Especially for applying patches and some other major changes. I use the SET HOST/LOG capability (or TELNET) to log an entire session where I log in to the SYSTEM account to make major changes before a reboot. It does take some discipline to remember to do this, but it has helped in many cases to track down small but consequential errors.

Another tool I use is redirecting the output of the startup process very early in the startup by inserting a front end startup procedure that sets up the log file and passes control over to the normal startup.

I'm attaching my current version of that startup procedure here. I control the selection of it by inserting the following in SYS$SYSTEM:MODPARAMS.DAT:

STARTUP = "SYS$SYSTEM:ALT_STARTUP.COM"

It's also possible to use PIPE or other mechanisms to build a T connection so that the output can go to the console and to a log file at the same time, but I haven't experimented with that. I usually find that it's sufficient to capture it to a log file.

I realize that the startup parameters allow you to have the startup procedure log most of the output to a file. I prefer this mechanism to capture all of the output from the very beginning of the invocation of STARTUP. I also like being able to control the name of the log file so that multiple boots log to files with different names.

Robert

Re: Recall Command

Zeni B. Schleter — Tue, 20 Dec 2005 10:33:32 GMT

We do use Set Host/Log when doing Installations . Very useful when doing repetive installs.
We use the Sysman method for startup and get the output in the standard startup.log. For shutdowns, we have started capturing that output in the method you described.