Spawn

[Petran Bisschops]

Hi,

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.

Petran.

[Wim Van den Wyngaert]

(enable audit if needed and) do anal/aud to see what is the problem.

Wim

[Mike Reznak]

Hi,

also MAXACCTJOBS, MAXDETACH, MAXJOBS matters. But -F-NOPRIV messages don't seem to point to this issue.

Mike

[Jan van den Ende]

Petran,

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.

hth,

Proost.

Have one on me.

jpe

[Petran Bisschops]

Hi,

Thanks for your replies so far.

Mike,
MAXACCTJOBS, MAXDETACH, MAXJOBS are all 0 on all configurations so that should not be causing the trouble.

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

Thanks,

Petran.

[Mike Reznak]

For Audit:

$ 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=

Mike

[Petran Bisschops]

Hi,

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?

Thanks,

Petran.

[Uwe Zessin]

What I have seen in the past was some very concerned system manager, who thought it was a good idea to remove read-access from files like F11BXQP.EXE.

[Wim Van den Wyngaert]

Petran,

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

Wim

[John Gillings]

Petran,
(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:

$ REPLY/ENABLE=SECURITY
$ SET AUDIT/ALARM/ENABLE=PRIVILEGE=FAILURE=ALL

Now try your unprivileged SPAWN.

Afterwards issue:

$ SET AUDIT/ALARM/DISABLE=PRIVILEGE=FAILURE=ALL

to stop the noise.

If that doesn't help, then try

$ REPLY/ENABLE=SECURITY
$ 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.

Don't forget

$ SET AUDIT/ALARM/DISABLE=PRIVILEGE=SUCCESS=ALL

to quiet things down.

[faris_3 · Accepted solution]

What is the definition of

$ show log lnm$temporary_mailbox /table=*


(should be LNM$JOB)

[Heinz W Genhart]

The logical name LNM$TEMPORARY_MAILBOX may point to LNM$GROUP.
So on such a system the users need the GRPNAM privilege to use the Spawn command.

Heinz

[Petran Bisschops]

Hi,

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

Petran.

[Wim Van den Wyngaert]

This is what the wizard says :

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

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

Wim : of course you need access to these logical name tables. That's why sysnam helps. Or putting an acl on the table.

Wim

[Uwe Zessin]

> "LNM$TEMPORARY_MAILBOX" = "LNM$SYSTEM" (LNM$SYSTEM_DIRECTORY)

Oh, great!!!

I bet you have a process control system in a manufacturing area that needs to run with all privileges :-(

[Ian Miller.]

An alternative would be to create a shared logical name table with appropritate ownership and protection and set LNM$TEMPORARY_MAILBOX to point to it.

[Petran Bisschops]

Hi,

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.

Thanks,

Petran.

[Uwe Zessin]

> however I have trouble understandinghow
> 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.

[faris_3]

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

DCL uses a temporary mailbox to communicate between the process and the subprocess.

[Jan van den Ende]

Petran,

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.

Proost.

Have one on me.

jpe

[Petran Bisschops]

Hi,

I guess this one is sorted now.

Thank you all for your help!

Petran.