- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- System services in an UWSS
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-11-2008 08:10 AM
тАО03-11-2008 08:10 AM
A while ago I asked how I could dynamically change identifiers (granted with ATTRIB=DYNAMIC) in a program written in C (thread: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1193355).
I decided to create an UWSS for it, with a different solution for on VAX (simply no disabling at login time; on VAX it's used only very incidentally :)
Now my problem is, in this UWSS I make several system service calls (SYS$GETJPIW, SYS$FIND_HOLDER, SYS$ASCTOID, SYS$GRANTID and SYS$REVOKID), but this results in:
%DCL-W-ACTIMAGE, error activating image SECURESHRP
-CLI-E-IMGNAME, image file $1$DGA1:[SYS2.SYSCOMMON.][SYSLIB]SECURESHRP.EXE
-SYSTEM-F-NOSHRIMG, privileged shareable image cannot have outbound calls
I can do without the SYS$ASCTOID, but the others happen to provide the main functionality of my service :-S
Is my approach an option at all, or am I doing something really stupid? Perhaps something in between....
Thnx in advance,
Oscar
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2008 01:25 PM
тАО03-11-2008 01:25 PM
Re: System services in an UWSS
Why a UWSS? This is something I would use from a sharable image instead.
Jur.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2008 02:01 PM
тАО03-11-2008 02:01 PM
Re: System services in an UWSS
If you're creating an Exec mode UWSS then it executes in Exec mode.
"Simply" drop the /protect on the link and you're away. Obviously you can't create a Kernel mode UWSS and ask it to use RMS, and for definitions of "simply" you should search this (sadly edited) forum and comp.os.vms. Here's one example: -
http://groups.google.com/group/comp.os.vms/msg/0b254f1816eb5ca5
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2008 02:02 PM
тАО03-11-2008 02:02 PM
Re: System services in an UWSS
There are a few folks around that find the UWSS interface valuable and that do use it, and find it valuable. I've encountered far too much pain with it to use it (lightly), though I have used it on a very few occasions. There are often better solutions.
The easiest here is probably to install the main image with the requisite privileges.
Somewhat different, but entirely functional, is to implement and use a subsystem identifier. This allows the application to grant an identifier, which can then be used to control access (directly, or possibly paired with another identifier) using an ACL on the target file(s) or other of the target objects.
Or launch an installed image as a subprocess and pass over or command. Or use DECnet task-to-task to launch a server process... In either case, the installed (executable) can call
If you do want to use the UWSS construction, absolutely everything involved in the outbound call must be installed protected or you'll get the NOSHRIMG message. And what you're calling needs to work correctly from inner-mode environments.
Part of the inherent "fun" of creating and maintaining and securing a UWSS is that a UWSS is privileged-mode code; the code is fully privileged because it is executing in an executive or kernel-mode environment, not because the code has privileges. And inner-mode code has its coding requirements, lest a security hole be created. It's this that is at the core of the NOSHRIMG check.
Poke around on the 'net NOSHRIMG topics and you should easily find some of my previous postings on this topic. Caution: you will encounter various (and potentially NSFW) responses to some my previous postings on this topic.
Stephen Hoffman
HoffmanLabs LLC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2008 04:29 PM
тАО03-11-2008 04:29 PM
SolutionYou can call system services from a UWSS. The trouble here is some of the routines you're trying to call aren't "real" system services! SECURESHRP is effectively another UWSS containing routines:
SYS$$SHOW_LOGICAL_NAMES
SYS$$SEND_SECSRV_MESSAGE
SYS$FINISH_UAI
SYS$CREATE_USER_PROFILE
SYS$SETUAI
SYS$GETUAI
SYS$CHECK_ACCESS
SYS$CHANGE_CLASS
SYS$REM_IDENT
SYS$REM_HOLDER
SYS$MOD_IDENT
SYS$MOD_HOLDER
SYS$FIND_HOLDER
SYS$FIND_HELD
SYS$CREATE_RDB
SYS$ADD_IDENT
SYS$ADD_HOLDER
So, it's $FIND_HOLDER that's causing you trouble.
If you want to persue the UWSS path, try hard coding a test case for whatever $FIND_HOLDER is doing for you and see if everything else works. Maybe you can make assumptions to skip that step? Otherwise, get hold of the sources and see what it's doing to see if you can reimplement it (more than likely it has to do with privileged access to SYSUAF).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-12-2008 07:22 AM
тАО03-12-2008 07:22 AM
Re: System services in an UWSS
Some of the suggestions where also given in the thread I referred to; for now I don't see an other practical solution.
But in the service I wrote was simply too much code (I tried it all in one module); moving everything (but the $GRANTID an $REVOKID) to a seperate module which is part of the main program, seems to do the trick!
Oscar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-16-2008 03:03 PM
тАО03-16-2008 03:03 PM
Re: System services in an UWSS
> moving everything (but the $GRANTID an
>$REVOKID) to a seperate module which is
>part of the main program, seems to do the
>trick!
That's a fairly general principle when writing privileged code - do as little as possible inside the privileged part.
Look in SYS$SHARE and you'll see several pairs of shareable images, for example SECURESHR & SECURESHRP, MAILSHR & MAILSHRP The "P" image contains the privileged operations, the other image is the public interface, and all the non-privileged code.
Have your outer layer do all the legwork, build some kind of data structure to describe what needs to be done (for example, an item list), then dispatch it to the privileged code to the the actual work. You'll still need to do the security checks in the lower layer, but things like translations are already done.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-17-2008 03:16 PM
тАО03-17-2008 03:16 PM
Re: System services in an UWSS
If I understand you correctly, you've written a System Service that takes any identifier and grants it to the process. (Maybe you even ask for a PID as well?)
Sounds delighful. Please let me know what it's called so I can keep an eye out for it.
When you're told "not to call out from inner-mode" the alternative is *not* to "do it in user-mode instead" but rather to duplicate the code for the callout routine in-line in the UWSS. Eg: If you don't think it's safe to call $getuai then you must open SYSUAF yourself in Exec-Mode and do your own retrieval in the UWSS and *not* ask some insecure user-mode code and/or memory to be the custodian of your data/parameters.
Once again, for your requirements, I'd suggest dropping the /PROTECT and /NOSYSSHR from the link command, but seeing as how you are using C (a language that is ill-suited to UWSSs) you can never be sure just which RTLs the compiler will call out to.
Regards Richard Maher
PS. When looking fo advice I suggest it might help to ask for advice and example from people who've actually written UWSSs.