topic Re: $ RUN/UIC vs. SYS$CREPRC in Operating System - OpenVMS

$ RUN/UIC vs. SYS$CREPRC

Willem Grooters — Fri, 24 Apr 2009 08:40:06 GMT

(VMS 7.3-2)

In DCL, I can create a proces under the same username but a different UIC:

$ run/uic='uic'/input='Runfile'/out='rlog' sys$system:loginout.exe -
/PROCESS_NAME='ProcesName' -
...

and BLA.COM is executed under that UIC. The drwaback is that the original user requires IMPERSONATE privilege.

To avoid this, I created a small program, doing the same but using the CREPRC system service, and installed it with IMPERSONATE privilege (Of course, after some checking to avoid abuse):

status = SYS$CREPRC (&pid,
&imgnam,
&inputfile_descr,
&outputfile_descr,
0, // errorfile
0, // privileges
&QuotaArray,
&runprcnam_descr,
0, // prioriteit
uic,
0, // term. mailbox
flg,
0, // itemlist
0, // node
0 ) ; // RAD

(imgnam = SYS$SYSTEM:LOGINOUT.EXE)

and the image is executed where I would otherwise use RUN/UIC.

The intended procedure is actually executed but the UIC of the process remains the one of the original user. But this change of UIC is required (for reasons not to be discussed here - I know there are better ways of doing this but this is what I'm to work with)

The flags I used is just PRC$V_DETACH (though the documentation sttaes IMPERSONATE, it's not found in prcdef on this VMS version)
Because DCL is involved, I need to use LOGINOUT.EXE, but the documentation isn't clear whether this will, or will not allow execution under a different UIC - opposite to DCL.

Is there a way to achieve my goal: Running a procedure under a different UIC - as a separate (sub)process, using the system service?

Re: $ RUN/UIC vs. SYS$CREPRC

Ian Miller. — Fri, 24 Apr 2009 09:54:34 GMT

I wonder if you need to set NOUAF as well.

Re: $ RUN/UIC vs. SYS$CREPRC

Wim Van den Wyngaert — Fri, 24 Apr 2009 10:01:44 GMT

You could also copy loginout.exe to a new file and install that with privs. And regulate access via an ACL.

Wim

Re: $ RUN/UIC vs. SYS$CREPRC

Willem Grooters — Fri, 24 Apr 2009 10:31:24 GMT

Ian: No change.
Wim: Nice thought but I doubt the system owner would accept this. Second, if such a check is made by LOGINOUT.EXE itself, it wouldn't help.

Re: $ RUN/UIC vs. SYS$CREPRC

Richard J Maher — Fri, 24 Apr 2009 10:40:19 GMT

Hi Willem,

Sorry to not answer your question directly but, please go the whole hog and stick a $persona_create + $persona_assume before the $creprc. Then you can drop the UIC altogether.

You need to install the program with SYSPRV as well as DETACH privs and organize access so not everyone can run it, but I'm guessing it's what you really want?

Cheers Richard Maher

PS. DOes anyone want to hear about my Mum's knee replacement and how long I've been spending in hospitals lately :-(

Re: $ RUN/UIC vs. SYS$CREPRC

Willem Grooters — Fri, 24 Apr 2009 11:14:17 GMT

Ian: Overlooked something: old version was still installed. After I corrected that error, NOUAF seems just what was needed. Sorry I cannot add points :)
Richard: I would have done so if there wasn't a time constraint with the customer.

Re: $ RUN/UIC vs. SYS$CREPRC

Willem Grooters — Fri, 24 Apr 2009 11:22:04 GMT

I found out that PRCDEF on our 7.3-2 system isn't in sync with the VMS System Services manual, so I had to code

flags= 0|PRC$M_DETACH|PRC$M_LOGIN

to get things going.

When in sync (VMS > 7.3-2), use:

flags= 0|PRC$M_IMPERSONATE|PRC$M_NOUAF

do not forget to INSTALL REPLACE the image afterwards :D

====
As has been quoted many many times: there are better ways to achieve the same thing. If possible, avoid this hack and use the advise given by Richard Mahler, Hoff, John Gillings and others.

Re: $ RUN/UIC vs. SYS$CREPRC

Hoff — Fri, 24 Apr 2009 13:46:02 GMT

Pragmatically, this stuff is the same. The:

flags= PRC$M_DETACH|PRC$M_LOGIN

is the same as:

flags= PRC$M_IMPERSONATE|PRC$M_NOUAF

with the bits renamed.

Notice the results of the following (yeah, its Bliss) search:

$ search sys$share:*.req PRC$M_IMPERSONATE,PRC$M_NOUAF,PRC$M_DETACH,PRC$M_LOGIN

******************************
SYS$COMMON:[SYSLIB]STARLET.REQ;1

literal PRC$M_NOUAF = %X'40';
literal PRC$M_DETACH = %X'200';
literal PRC$M_LOGIN = %X'40';
literal PRC$M_IMPERSONATE = 512;

The values of PRC$M_NOUAF and PRC$M_LOGIN match, and PRC$M_DETACH and PRC$M_IMPERSONATE (after converting bases) match.

The fundamental error here is the assumption that the context is comprised of "just" the UIC. That was mostly the case back in RSX-11M, but in OpenVMS and particularly in OpenVMS after V6.0, there's way, way, way _way_ more to the process context than "just" the UIC.

I generally suggest the use the persona services; those tend to get this stuff right, where changing "just" the UIC tends to lead to weirdness and pain.

If you want to update your C library reference area, the LIBEXT tool on the Freeware V7.0 is what the C installation kits once used; it's a wildcard library extraction tool.

Re: $ RUN/UIC vs. SYS$CREPRC

Willem Grooters — Fri, 24 Apr 2009 18:11:10 GMT

I know it's the same. It's just that prcdef.h on these systems is not in line with the docs. I ran into this because usage of PRC$M_IMPERSONATE and PRC$M_NOUAF caused compilation errors; you just must be aware of the issue ;)

Re: $ RUN/UIC vs. SYS$CREPRC

John Gillings — Sun, 26 Apr 2009 21:46:32 GMT

General comment about PRC$M_NOUAF ...

When you run LOGINOUT in a detached process *WITHOUT* specifying PRC$M_NOUAF for $CREPRC, or *WITH* /AUTHORIZE on the DCL RUN command, (note that the default is reversed between the two), many of the process attributes you have specified with qualifiers or parameters may be overridden in the resulting process.

That includes UIC, process name, quotas and privileges. Behind the scenes, the process is created with whatever you specified, but LOGINOUT replaces them with values from the UAF.

This is all documented in the IDSM. Creating processes is complex, and loaded with pitfalls, defaults, default defaults, minima and other overrides. Test your code carefully, and examine resulting processes from SDA to make sure everything is correct.

Note that the official Compaq/HP "Programming OpenVMS System Services" training course has a fairly serious error along these lines in the $CREPRC example - it's supposed to be setting working set parameters, but manages to to a CPU limit instead.

Willem, double check your QuotaArray variable. Don't trust listings or even DEBUG. You need to be able to examine it as raw quadword hex values and verify that all the fields really are in the right place. To get it right, it needs to be declared as unaligned.