- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: CREPRC and LOGINOUT and QUOTAS
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
Forums
Discussions
Discussions
Discussions
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
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
08-30-2006 01:55 AM
08-30-2006 01:55 AM
...
status = sys$creprc(&pid, &imagename,
&inputname, &outputname, &errorname,
&prvmask, "a, &procname, priority,
uic, 0, stsflag);
...
imagename is set to "sys$system:loginout.exe" and inputname points to a .com file with some DCL commands (including a RUN command). Stsflag is also set to PRC$M_DETACH.
Everything works fine, but I don't see in the running process the quotas, as set (increased) by the quota list parameter! They are still the same of the user that run the service.
Is it possible to start a CLI via loginout with different quotas from the creator ones? Does it depend on a correct combination of privileges, uic, status or any other $creprc parameter that I misused?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 02:11 AM
08-30-2006 02:11 AM
Re: CREPRC and LOGINOUT and QUOTAS
welcome to the OpenVMS ITRC forum.
Please check the documentation of $CREPRC, especially the chapter about 'Use of Quota List'.
http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_025.html#jun_147
This explains, that the creating process needs IMPERSONATE or CMKRNL privilege to create a detached process with higher quota values than itself.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 02:35 AM
08-30-2006 02:35 AM
Re: CREPRC and LOGINOUT and QUOTAS
Anyway, I forgot to specify that -just to avoid such troubles with privileleges- we always give our application all priv's:
/* initialize process privileges */
prvmask[0] = 0xFFFFFFFF;
prvmask[1] = 0xFFFFFFFF;
This is because our server is dedicated to a single application (there are not interactive users working on it), so the security is not an issue.
The point for me was -if it was at still _possible_ to do that call, because I was not sure this kind of quota setting could work with the "loginout" feature.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 02:38 AM
08-30-2006 02:38 AM
Re: CREPRC and LOGINOUT and QUOTAS
the process calling the $CREPRC system service needs those privs, not the created detached process running LOGINOUT.EXE.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 02:48 AM
08-30-2006 02:48 AM
Re: CREPRC and LOGINOUT and QUOTAS
I'd to list my own privileges (which are the privileges for all the application users):
Authorized (and default) Privileges:
ALTPRI BYPASS CMEXEC CMKRNL DIAGNOSE GROUP
GRPNAM IMPERSONATE LOG_IO NETMBX PHY_IO PRMCEB
PRMMBX SETPRV SYSGBL SYSLCK SYSNAM SYSPRV
TMPMBX VOLPRO WORLD
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 03:01 AM
08-30-2006 03:01 AM
Re: CREPRC and LOGINOUT and QUOTAS
if it still doesn't work, consider checking the use of the PRC$M_NOUAF stsflg.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 03:15 AM
08-30-2006 03:15 AM
Re: CREPRC and LOGINOUT and QUOTAS
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 03:52 AM
08-30-2006 03:52 AM
Re: CREPRC and LOGINOUT and QUOTAS
%SYSTEM-F-EXLNMQUOTA, logical name table is full
But this is not a PQL parameter...!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 04:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 10:04 AM
08-30-2006 10:04 AM
Re: CREPRC and LOGINOUT and QUOTAS
The quota list (PQL) is a complex entity, please read the description in the System Services Reference Manual very carefully.
In addition to the interactions beyween supplied, default and minimum values, the calling process needs IMPERSONATE or CMKRNL to grant a quota higher than their own.
Another potential issue is the PQL structure itself. Since it's unaligned, you need to explicitly disable member alignment when declaring it, like this:
#pragma __member_alignment __save
#pragma __nomember_alignment
typedef struct _pqls
{ char item;
int value;
} pqls;
pqls quota[10];
#pragma __member_alignment __restore
It's difficult to alignment detect errors, as examining the source code, or even the structure under DEBUG, everything will look OK, but $CREPRC will see something very odd because the value field will (by default) be aligned on a longword boundary, rather than immediately following the item code byte. Try examining your quota structure with DBG> EXAMINE/LONG/HEX and make sure all the fields are exactly where you want them to be.
I recommend you experiment with a detached process executing a procedure that just lists the actual process quotas and privileges with F$GETJPI and convince yourself that you can specify precisely what you want.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 10:45 AM
08-30-2006 10:45 AM
Re: CREPRC and LOGINOUT and QUOTAS
Please reconsider your comment concerning privileges.
Having developed OpenVMS applications since VAX/VMS 1.0, I can assure that in most cases, you do not need the privileges.
While at the present time, your applications is in a dedicated environment, it is not unusual for a later situation to arise where the privileges become an issue. It is often a more significant problem to remove privileges later.
Privileges are also an important part of the OpenVMS philosophy that creates the long uptimes that are so valued in our community. I have seen more system crashes caused directly, or indirectly by unneeded privileges than I care to count. Elevated privilegs should, IMO, be used only when absolutely (and I do mean ABSOLUTELY) necessary. In nearly 30 years, I can say that it is a relatively rare application that needs privileges, particularly DEVOUR-class privileges.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2006 11:40 PM
08-30-2006 11:40 PM
Re: CREPRC and LOGINOUT and QUOTAS
Now my process is up and running, and the last correction was -as suggested by Volker- setting the proper PQL$_JTQUOTA value along with the PRC$M_NOUAF flag.
I already had my applications byte-aligned (they need a low-level communication with db and plc's), so all structure boundaries were actually correct.
Just few words for Robert. I understand your point, that -after all- is mine, too. The fact is, that we never went deeper in security and configuration issues, even 15 years ago, when we were starting the VMS "adventure". Now we passed from 6-10 guys to... almost one (myself), and taking up this matter again is not as easy as was once (as you can see...). I'll try to reconsider that issue in future.
Thanks you all a lot for your effective cooperation and support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2008 04:37 AM
04-03-2008 04:37 AM