Recall Command

[Zeni B. Schleter]

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 .

[Ian Miller.]

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

[Volker Halle]

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.

[Zeni B. Schleter]

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.

[Heinz W Genhart]

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

[Zeni B. Schleter]

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

[Zeni B. Schleter]

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

[Zeni B. Schleter]

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.

[Volker Halle]

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.

[Hein van den Heuvel]

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.

[Robert_Boyd]

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

[John Gillings]

>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)

[John Gillings]

Oops, forgot...

From Alpha it's

SDA> READ SYS$LOADABLE_IMAGES:DCLDEF

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

[Hein van den Heuvel]

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.

[Kris Clippeleyr]

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)

[Ian Miller.]

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

[Ian Miller.]

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?

[Zeni B. Schleter]

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.

[Robert_Boyd]

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

[Zeni B. Schleter]

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.

[John Abbott_2]

We also use set host/log &...
We have Security audit alarms on reboot command, data files, SYSGEN changes etc. When they change an alarm is generated & we keep the events in realtime (off of the modified system). These events are reviewed, it gives the collective sysmgrs a chance to ask questions so that all are usually clued up before the next reboot (never a crash! :-))

With the recall buffer (SDA CLUE PROCESS/RECALL). Any usage of, for example John's point...

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

Doesn't display the password. Which is nice. Of course you can end up with sensitive information from the recall buffer.

Kind Regards
John.

[Zeni B. Schleter]

In practice , we use command procedures to do file copies so that passwords are not echoed. It started as an aid to help users with the syntax. After 20 years it is ingrained. I have streamlined the syntax of the procedure that I use to look like I have a proxy except that I get prompted for the password with echo-off. Usual precaution with regards to "Set Verify" are taken.
Nothing is given with the usual recall command but I will check the results with CLUE PROCESS/RECALL.

[Lawrence Czlapinski]

Zeni: When we need a record of what was done we use either
$SET HOST/LOG
or
Polycenter Console Manager
Polycenter Console Manager works best for us since the log is automatic.
Audit alarms may be useful for knowing that key files were changed.
There are privileged apps and privileged users. You could use logfiles for privileged apps. Logfiles doesn't work as well for privileged users.
Lawrence

[Zeni B. Schleter]

Thanks for the input.

[Jo Torsmyr]

Hi Kriss!

I stumbled across this thread by accident ;-)

It must be close to 20 years since i wrote the
RETRIEVE program to overcome the annoying
limitations of RECAL. I am not sure where I
have the original source code now, if you
know where I can find it I would appreciate it!

Best
-jo