Privileges needed for DCL SPAWN command?

[Eric W. Robertson]

I do not remember a process requiring any special privilege to use the DCL SPAWN command. I have a user account with the following summary from AUTHORIZE:

Username: TEST Owner: VMS Account for testing
Account: UIC: [201,1] ([TEST_USERS,TEST])
CLI: DCL Tables: DCLTABLES
Default: USER_ROOT:[TEST_Users.test]
LGICMD:
Flags: PwdMix
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: (none) Pwdchange: (pre-expired)
Last Login: 26-JUL-2010 12:14 (interactive), 23-JUL-2010 16:03 (non-interactive)
Maxjobs: 0 Fillm: 128 Bytlm: 800000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 1000 JTquota: 8192
Prclm: 20 DIOlm: 1000 WSdef: 4096
Prio: 4 ASTlm: 300 WSquo: 8192
Queprio: 4 TQElm: 100 WSextent: 16384
CPU: (none) Enqlm: 4000 Pgflquo: 2000000
Authorized Privileges:
NETMBX TMPMBX
Default Privileges:
NETMBX TMPMBX
Identifier Value Attributes
IQWARE_USER %X80010014

When I login using this user's account, I get the following error message when attempting to use the DCL SPAWN command in its simplest form:

$ set host 0

Welcome to IQware's ES45 Development System #1 OpenVMS (TM) Alpha Operating System, Version V8.3

Username: TEST
Password:
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.3 on node IQDEV1
Last interactive login on Monday, 26-JUL-2010 12:31:28.96
Last non-interactive login on Friday, 23-JUL-2010 16:03:20.44
1 failure since last successful login

$ SPAWN
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
$ logout
TEST logged out at 26-JUL-2010 13:01:21.79
%REM-S-END, control returned to node LOCAL:.IQDEV1::

Is there a new privilege needed for a process to use the SPAWN command?

Thanks in advance for any wisdom,

Eric

[Steven Schweda]

> I do not remember a process requiring any
> special privilege to use the DCL SPAWN
> command.

That may be because none is needed.

alp $ show proc /priv

26-JUL-2010 12:13:43.25 User: SMS Process ID: 20208D7F
Node: ALP Process name: "SMS_1618"

Authorized privileges:
NETMBX TMPMBX

Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox
[...]

alp $ spawn
%DCL-S-SPAWNED, process SMS_12749 spawned
%DCL-S-ATTACHED, terminal now attached to process SMS_12749


> $ SPAWN

show symbol spawn

> Is there a new privilege needed [...]

Define "new".

alp $ write sys$output f$getsyi( "version")
V8.3

I know nothing, but I can imagine that the
protections could have been damaged on some
program or other file, or that something
which needs to be INSTALLed with privileges
wasn't.

[Hein van den Heuvel]

The important controls for 'spawn' are the CAPTIVE and RESTRICTED flags in the authorization record. Neither is in play it seems.

And one needs TMPMBX, which is there in authorize. Is it still there after (sy)login?
Do a SHOW PROC/PRIV !?

Is the SPAWN command clean?
No symbol defined for it?

My WAG is a bad definition for the logical name: LNM$TEMPORARY_MAILBOX

See: http://h71000.www7.hp.com/doc/84final/4527/4527pro_024.html#jun_143

If the problem persists, then it would not hurt to check the LIB$SPAWN doc for clues:

http://h71000.www7.hp.com/doc/82final/5932/5932pro_045.html#spawn

And I'd use SET WATCH /CLA=MAJOR to see if the spawn is trying to touch a file it can not.... but that needs CMKRNL.

hth,
Hein

[John Gillings]

Eric,

You should only need TMPMBX to create the temporary mailbox your process uses to talk to the subprocess, but check:

$ show log/table=*directory* lnm$temp*

The default is:

(LNM$SYSTEM_DIRECTORY)
"LNM$TEMPORARY_MAILBOX" = "LNM$JOB"

but if redefined anywhere else, you will need privilege to write into the target logical name table. You can force it back with:

$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$JOB

If that doesn't help, use auditing.

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

Warning - this might be noisy. Maybe have a disable command typed and ready to hit ENTER on another terminal:

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

[Eric W. Robertson]

Thanks guys. It turned out that we had changed the definition for the logical name table for temporary mailboxes for this account so that it could communicate with other processes in the same group using VMS mailboxes. But, it did not have privilege to write to the LNM$GROUP table when creating the mailbox which is why spawn was returning NOPRIV.

Thanks for the clues!

[Eric W. Robertson]

This thread is now closed.