- Integrated Systems
- About Us
- Integrated Systems
- About Us
11-15-2005 09:28 PM
I have installed the same project with the same settings (software/uic/uaf accounts etc) on 5 different machines. On one machine, a SPAWN command for a user account with only NETMBX and TMPMBX does not work e.g. give the error message:
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
The account has PRCLM set to 10 in UAF and no further UAF settings that could cause problems - as far as I can see.
Can anybody tell me which other parameter could possibly cause this protection violation?
Your help is much appreciated.
Solved! Go to Solution.
11-15-2005 10:25 PM
also MAXACCTJOBS, MAXDETACH, MAXJOBS matters. But -F-NOPRIV messages don't seem to point to this issue.
11-15-2005 11:12 PM
this can (but needs not be) caused by the setting of SYSGEN param SECURITY_POLICY.
Compare the values on the different machines, and if they are not equal, do a SYSGEN HELP SYS_PAR SECURITY to find out about the various possibilities.
Again, this could be the issue, but it is not sure.
Have one on me.
11-16-2005 12:02 AM
Thanks for your replies so far.
MAXACCTJOBS, MAXDETACH, MAXJOBS are all 0 on all configurations so that should not be causing the trouble.
The SYSGEN param SECURITY_POLICY is set to 7 on all configurations. As far as I can judge only bit 6 to allow SPAWN in CAPTIVE accounts matter but we don't have the captive flag set so this should not be causing trouble.
I will try to see if I can get any info via audit as Wim suggested but I have to figure out how this works first....
So in the mean time, I am still open for any suggestions.
11-16-2005 12:27 AM
$ SHOW AUDIT shows you, what audits and alarms are set.
for tracing the problem like this is good to have Alarms enabled. Then after you enable opcom security messages $ REPLY/ENABLE=SECURITY you will se the messages on the terminal screen. But do not use alarms, when you create hundreds of subprocesses in a minute. Then its better to anable audits and analyze audit file afterwards.
To enable Alarm for subprocesses.
$ SET AUDIT/ALARM/ENABLE=(LOGIN=SUBPROCESS,LOGFAILURE=SUBPROCESS)
To enable Audit for subprocesses.
$ SET AUDIT/AUDIT/ENABLE=(LOGIN=SUBPROCESS,LOGFAILURE=SUBPROCESS)
to disable it use /DISABLE= instead of /ENABLE=
11-16-2005 12:48 AM
Mike, I used the audit commands as you suggested but it does not generate an event if I try a spawn.
I did find out that if I give the account SYSPRV, the spawn command works....
Are there any access restrictions to the executable implementing the $SPAWN command?
11-16-2005 12:48 AM
11-16-2005 03:19 AM
I guess your spawn failed before it was created. You should audit your file operations :
$ set audit/audit/enable=(access=failure:(read,write,execute,delete,control))
If checked all accesses done by spawn :
(with userid of spawner)
RE on loginout.exe
RE on dcl.exe
RE on dcltables.exe
RE on cliutlmsg.exe
11-16-2005 12:37 PM
(WARNING - be careful doing this on a busy system, you could get a whole lot of output!)
Try this, make sure you have plenty of scroll back on your terminal:
$ SET AUDIT/ALARM/ENABLE=PRIVILEGE=FAILURE=ALL
Now try your unprivileged SPAWN.
$ SET AUDIT/ALARM/DISABLE=PRIVILEGE=FAILURE=ALL
to stop the noise.
If that doesn't help, then try
$ SET AUDIT/ALARM/ENABLE=PRIVILEGE=SUCCESS=ALL
now issue your SPAWN from the SYSPRV account and see what SYSPRV is used for. It should also tell you if the NOPRIV is from the parent or the subprocess.
$ SET AUDIT/ALARM/DISABLE=PRIVILEGE=SUCCESS=ALL
to quiet things down.
11-18-2005 10:31 PM
So on such a system the users need the GRPNAM privilege to use the Spawn command.
11-20-2005 07:20 PM
As suggested by Homi, the assignment of the logical LNM$TEMPORARY_MAILBOX has been causing the problem.
$ sho log LNM$TEMPORARY_MAILBOX /table=*
"LNM$TEMPORARY_MAILBOX" = "LNM$SYSTEM" (LNM$SYSTEM_DIRECTORY)
1 "LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY)
If I give the account the SYSNAM priv, the spawn command works...
After I redefined it to point to the job table, the unprivileged spawn worked.
There are several other projects running on the "problem" node - one of them must have configured/coded the re-assignment of this logical without knowing the impact.
However, can somebody tell me why this setting causes SPAWN to fail and the context i.e. parent process or sub-prcess context.
11-20-2005 08:33 PM
Normally, LNM$TEMPORARY_MAILBOX specifies LNM$JOB, the job-wide logical
name table; thus, only processes in the same job as the process that first
creates the mailbox can use the logical name to access the temporary
mailbox. If you want to use the temporary mailbox to enable communication
between processes in different jobs, you must redefine LNM$TEMPORARY_
MAILBOX in the process logical name directory table (LNM$PROCESS_
DIRECTORY), to specify a logical name table that those processes can
For instance, if you want to use the mailbox as a communication device for
processes in the same group, you must redefine LNM$TEMPORARY_MAILBOX to
specify LNM$GROUP, the group logical name table. The following DCL command
assigns temporary mailbox logical names to the group logical name table:
$DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$GROUP
Because $QIOW is used for input and output rather than $QIO, both MAILS
and MAILR wait for I/O to complete before advancing to the next program
Wim : of course you need access to these logical name tables. That's why sysnam helps. Or putting an acl on the table.
11-20-2005 08:44 PM
I bet you have a process control system in a manufacturing area that needs to run with all privileges :-(
11-20-2005 09:24 PM
Purely Personal Opinion
11-20-2005 09:40 PM
Uwe - your guess was spot on... In the old days, every project had it's own VAX and they could do whatever they wanted with the machine but in todays phylosophy of cutting costs etc. they have to share the hardware amongst different projects. If the projects are setup properly, assigning this logical to LNM$GROUP should suffice....
Wim, I am/was aware of the existence and functionality of the logical LNM$TEMPORARY_MAILBOX - however I have trouble understandinghow the setting of this logical could lead to failure of the SPAWN command.
11-20-2005 09:55 PM
> the setting of this logical could lead to
> failure of the SPAWN command
On my system, I see a logical DCL$ATTACH_pidOfMasterProcess in LNM$JOB after the SPAWN command.
11-21-2005 01:57 AM
DCL uses a temporary mailbox to communicate between the process and the subprocess.
11-21-2005 02:14 AM
to put in in clear words:
- The communication between a process and its (spawned) subprocess uses a temporary mailboxes
- Those processes "know" which mailbox to use by defining it in LNM$TEMPORARY_MAILBOX
- To define a logical name in a table you need WRITE access to that table
- SYSTEMwide or GROUPwide tables need SYSNAM or GROUPNAM privs to write to them.
Have one on me.