- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: $ RUN/UIC vs. SYS$CREPRC
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
тАО04-24-2009 01:40 AM
тАО04-24-2009 01:40 AM
$ RUN/UIC vs. SYS$CREPRC
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?
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 02:54 AM
тАО04-24-2009 02:54 AM
Re: $ RUN/UIC vs. SYS$CREPRC
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 03:01 AM
тАО04-24-2009 03:01 AM
Re: $ RUN/UIC vs. SYS$CREPRC
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 03:31 AM
тАО04-24-2009 03:31 AM
Re: $ RUN/UIC vs. SYS$CREPRC
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 03:40 AM
тАО04-24-2009 03:40 AM
Re: $ RUN/UIC vs. SYS$CREPRC
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 :-(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 04:14 AM
тАО04-24-2009 04:14 AM
Re: $ RUN/UIC vs. SYS$CREPRC
Richard: I would have done so if there wasn't a time constraint with the customer.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 04:22 AM
тАО04-24-2009 04:22 AM
Re: $ RUN/UIC vs. SYS$CREPRC
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 06:46 AM
тАО04-24-2009 06:46 AM
Re: $ RUN/UIC vs. SYS$CREPRC
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2009 11:11 AM
тАО04-24-2009 11:11 AM
Re: $ RUN/UIC vs. SYS$CREPRC
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2009 02:46 PM
тАО04-26-2009 02:46 PM
Re: $ RUN/UIC vs. SYS$CREPRC
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.