System services in an UWSS

[Oscar van Eijk]

Hi All,

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

[Jur van der Burg]

A UWSS is, like its name says, a system service and thus it runs in kernel mode. So there are restrictions, like calling an external image like secureshrp that contains some services like the ones you are calling.

Why a UWSS? This is something I would use from a sharable image instead.

Jur.

[Richard J Maher]

Personally, I don't see and [K]ernel in U.W.S.S.

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

[Hoff]

The UWSS privileged shareable image construct is fairly weak as OpenVMS programming mechanisms go and something that probably didn't work out nearly as well as its designers had intended, and it can have its own specific risks. I prefer to avoid it.

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.

[John Gillings · Accepted solution]

Oscar,

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

[Oscar van Eijk]

Thanks for your answers!
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

[John Gillings]

Oscar,

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

[Richard J Maher]

Marvellous!

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.