- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Recall Command
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 05:40 AM
тАО12-19-2005 05:40 AM
Re: Recall Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 08:51 AM
тАО12-19-2005 08:51 AM
Re: Recall Command
>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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 08:56 AM
тАО12-19-2005 08:56 AM
Re: Recall Command
From Alpha it's
SDA> READ SYS$LOADABLE_IMAGES:DCLDEF
you will also have to increase the examine size from ";400"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 09:20 AM
тАО12-19-2005 09:20 AM
Re: Recall Command
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 06:49 PM
тАО12-19-2005 06:49 PM
Re: Recall Command
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 09:55 PM
тАО12-19-2005 09:55 PM
Re: Recall Command
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2005 10:55 PM
тАО12-19-2005 10:55 PM
Re: Recall Command
Parhaps using the LOGGER program or similar may be the best way forward.
What is the reason for the record?
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-20-2005 12:51 AM
тАО12-20-2005 12:51 AM
Re: Recall Command
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-20-2005 02:27 AM
тАО12-20-2005 02:27 AM
Re: Recall Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-20-2005 02:33 AM
тАО12-20-2005 02:33 AM
Re: Recall Command
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.