- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- "Hang" on return
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
тАО03-15-2009 07:08 PM
тАО03-15-2009 07:08 PM
Re: "Hang" on return
Rather than trying to plug all the inevitable holes in your SETENV utility (it will be a never ending task!), why not do this using existing, working and supported mechanisms?
First thing that springs to mind is:
$ SUBMIT/USER=TOMG2
$ SYNCHRONIZE/ENTRY='$ENTRY'
$ stat=$STATUS
Yes, SUBMIT/USER is a privileged command, but you have the required privileges.
There are many other possibilities.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-15-2009 11:48 PM
тАО03-15-2009 11:48 PM
Re: "Hang" on return
Jan: No, entirely different
John: this might be a better solution _in this case_ but it's not always applicable. The same sequence can be executed by non-privileged users in which case SUBMIT/USER is not possible. Besides - the method has been in use over 10 years and is embedded in quite a few (production) scripts....
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-15-2009 11:57 PM
тАО03-15-2009 11:57 PM
Re: "Hang" on return
write sys$output f$mes(%xf48009)
%SDA-S-SUCCESS, success
fwiw
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2009 05:35 AM
тАО03-16-2009 05:35 AM
Re: "Hang" on return
I've done some more investigation with two processes; one using the old image, the other using the new. In both; I executed SPAWN and SETENV; then, I analyzed the system and rercorded JIB, PCB and PHD, and compared the outcome (just the labels and values; addresses removed. The result v=can be found in the attachement. Most differences are obvious, but I do have one that I could not explain; that one is a few lines below PCB$L_INITIAL_KTB in the form,marked "******"in the center.
Could it be that some P1 data needs to be altered? If so,what would I need to look at?
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2009 06:04 AM
тАО03-16-2009 06:04 AM
Re: "Hang" on return
DCL does not expect processes to swap identities on the fly.
SET UIC (deprecated) regularly blows up processing with DCL, for instance.
Spoofing code also tends to break at upgrades.
And some of the spoofing code I've reviewed has introduced more and larger security holes than its authors had intended to plug.
Find and use another way to reach your goals here. Create a server and pass command(s) into it. Or better (since passing in user commands is a path for injection) pass in requests or codes using a fixed and known grammar.
And yes, I know you'll ignore the comments here. Why? Well, I ignored the folks that tried to tell me this, too. A design that allows spoofing the user security context on the fly in an interactive or command-level environment is generally somewhere between a Really Bad Idea and a Massively Bad Idea. (qv: XSS, SQLI, etc.) Simplify the design. Mailboxes and hangs are the least of the issues.
Put another way, I'd suggest a redesign here. It'll be easier to support, easier to maintain, easier to lock down, and the results will survive upgrades.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2009 07:31 AM
тАО03-16-2009 07:31 AM
Re: "Hang" on return
We're well on the way for that:
Without SPAWN, it's fine.
With SPAWN, it's fine once the situation is set back to normal. But if the subprocess finishes before that, the main process is not notified. There must be something within VMS that causes this to happen; the only question is: What.
(Once I know that, the program could be altered to work properly. That will be the last change made to the code - further maintenance is not foreseen.)
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2009 09:44 AM
тАО03-16-2009 09:44 AM
SolutionThis is easy to demonstrate:
$ SPAWN
%DCL-S-SPAWNED, process GOODMAN_55891 spawned
%DCL-S-ATTACHED, terminal now attached to process GOODMAN_55891
$ SET UIC [100,1]
$ SET PROCESS/PRIV=NOBYPASS
$ LOG
Process GOODMAN_55891 logged out at 16-MAR-2009 17:37:05
(parent process hangs)
--------------------------------------------
$ SPAWN
%DCL-S-SPAWNED, process GOODMAN_13828 spawned
%DCL-S-ATTACHED, terminal now attached to process GOODMAN_13828
$ SAY F$GETJPI(0,"TMBU")
3078
$ SHOW DEVICE/FUL MBA3078:
Device MBA3078:, device type local memory mailbox, is online, record-oriented
device, shareable, mailbox device.
Error count 0 Operations completed 1
Owner process "" Owner UIC [STAFF,GOODMAN]
Owner process ID 00000000 Dev Prot S,O:RWPL,G,W
Reference count 1 Default buffer size 256
$ SET SECURITY /CLASS=DEVICE MBA3078: /PROTECTION=W:RWED
$ SET UIC [100,1]
$ SET PROCESS/PRIV=NOBYPASS
$ LOG
Process GOODMAN_13828 logged out at 16-MAR-2009 17:43:11
%DCL-S-RETURNED, control returned to process GOODMAN
$
(parent process resumes)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2009 10:00 AM
тАО03-16-2009 10:00 AM
Re: "Hang" on return
Thanks for confirming what several suspected.
Nice & easy reproducer. So the solution for Wim will be to add code to change the process termination mailbox protection or owner.
Hein.
JPI$_TMBU
Returns the termination mailbox unit number, which is a longword integer value.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2009 02:09 PM
тАО03-16-2009 02:09 PM
Re: "Hang" on return
(not sure why I bother answering your questions when you invariably ignore the advice, but anyway...)
OK, so the problem is really that your procedure exits abnormally, preventing your SETENV from reverting to the old environment, so it can't write to the mailbox etc...
Rather than trying to fix the flawed mechanism, how about trying to ensure the reversion happens regardless of what the procedure does? Since I don't know the nature of what it's doing, or how its failing, here are a few suggestions:
$ SPAWN PIPE SETP tomg2 ; SET NOON ;
$ SPAWN PIPE SETP tomg2 ; SPAWN @procedure ; SETENV TOMG1
Failing that, you could use a big hammer and fix the protection on the mailbox prior to fiddling the UIC. Of course, this opens a potential security hole of sorts, as anyone will be able to write to the mailbox
$ SPAWN PIPE SET SECURITY/CLASS=DEVICE/PROTECTION=(W:RW) DCL$ATTACH_'F$GETJPI("","PID")' ; SETP tomg2 ;
Note that the F$GETJPI executes in the context of the parent process, so it gets the correct mailbox name.
To plug the security hole you could insert an ACE granting access only to the user to which you're going to SETP, rather than the blunt instrument "W:RW". Once that's done, you may even be able to eliminate the SETENV to revert.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-17-2009 12:01 AM
тАО03-17-2009 12:01 AM
Re: "Hang" on return
Hein: That will do for that; I already add an ACE to the terminal, I can easily add another device :)
John: See my comment on Hoff. I can't change things here.
Your last suggestion on how to change the ACL on the termination mailbox is what I will insert.
OpenVMS Developer & System Manager