topic Re: Spawn in Operating System - OpenVMS

Spawn

Petran Bisschops — Wed, 16 Nov 2005 05:28:24 GMT

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.

Re: Spawn

Wim Van den Wyngaert — Wed, 16 Nov 2005 05:37:30 GMT

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

Wim

Re: Spawn

Mike Reznak — Wed, 16 Nov 2005 06:25:45 GMT

Hi,

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

Mike

Re: Spawn

Jan van den Ende — Wed, 16 Nov 2005 07:12:23 GMT

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

Re: Spawn

Petran Bisschops — Wed, 16 Nov 2005 08:02:07 GMT

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.

Re: Spawn

Mike Reznak — Wed, 16 Nov 2005 08:27:33 GMT

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

Re: Spawn

Petran Bisschops — Wed, 16 Nov 2005 08:48:04 GMT

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.

Re: Spawn

Uwe Zessin — Wed, 16 Nov 2005 08:48:57 GMT

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.

Re: Spawn

Wim Van den Wyngaert — Wed, 16 Nov 2005 11:19:26 GMT

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

Re: Spawn

John Gillings — Wed, 16 Nov 2005 20:37:30 GMT

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.

Re: Spawn

faris_3 — Thu, 17 Nov 2005 05:07:18 GMT

What is the definition of

$ show log lnm$temporary_mailbox /table=*

(should be LNM$JOB)

Re: Spawn

Heinz W Genhart — Sat, 19 Nov 2005 06:31:52 GMT

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

Re: Spawn

Petran Bisschops — Mon, 21 Nov 2005 03:20:59 GMT

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.

Re: Spawn

Wim Van den Wyngaert — Mon, 21 Nov 2005 04:33:48 GMT

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

Re: Spawn

Uwe Zessin — Mon, 21 Nov 2005 04:44:25 GMT

> "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 :-(

Re: Spawn

Ian Miller. — Mon, 21 Nov 2005 05:24:05 GMT

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.

Re: Spawn

Petran Bisschops — Mon, 21 Nov 2005 05:40:00 GMT

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.

Re: Spawn

Uwe Zessin — Mon, 21 Nov 2005 05:55:17 GMT

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

Re: Spawn

faris_3 — Mon, 21 Nov 2005 09:57:10 GMT

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

Re: Spawn

Jan van den Ende — Mon, 21 Nov 2005 10:14:05 GMT

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