NOPRIV Privilege problem with pipe sys$pipe on Vms 732

[Miguel Ward]

Hi:

On Vms 732 I get error which does not happen on 83 which is breaking Oracle 9208 execution, I can workaround it by modifying Oracle scripts but would like to know if you people get same error?, I have most Vms patches installed including 'DEC AXPVMS VMS732_UPDATE V9.0'

I have isolated error so as simplify test:

Vms 732:

set proc/priv=(noall,tmpmbx,netmbx)
pipe dir | search sys$pipe "hello"
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

On Vms 83:

set proc/priv=(noall,tmpmbx,netmbx)
pipe dir | search sys$pipe "hello"
%SEARCH-I-NOMATCHES, no strings matched

With privileges everything works ok (I have not got around to determine yet which privilege is needed in particular).

Thanks

Miguel

[Jan van den Ende]

Miguel,

What is the result of a plain DIR command in the same environment?
My guess is that you will get that same error (maybe only at one, or a few files); that it has nothing to do wit the PIPE construct.
I think it simply means that you are not authorised to read (all, some?) files in that environment.

Now just some guesswork, sorry beforehand if I did draw some incorrect conlusions:

by the way, what are you trying to achieve with
$ pipe dir | search sys$pipe "hello"
Are you looking for any files with the substring HELLO as part of the name?
the much more efficient way to do that would be
$ dir *hello*
or are you searching the files in the directory for the string HELLO ?

that you can achieve by
$ search *.* hello .
your construct searches the directory LISTING for the string!

Proost.

Have one on me.

jpe

[Hoff · Accepted solution]

Enable OpenVMS system security auditing for privilege failures (if such is not already enabled), retry the failing operation, and then watch for the security audit or the alarm.

SHOW AUDIT and SET AUDIT control what is audited, and ANALYZE/AUDIT is the command to read the log. If security alarms are enabled, REPLY /ENABLE=SECURITY and then REPLY /DISABLE=SECURITY bracketing around the failing PIPE command will show the alarms.

FWIW, don't bother to try SEARCH with /WINDOW, as that qualifier doesn't work in a pipe.

Stephen Hoffman
HoffmanLabs LLC

[Miguel Ward]

Thanks for prompt response.

The dir command was just an example, a bad one.

The 'real' command Oracle procedures are issuing is:

$ pipe/trusted show process/rights | search/nowarn/nooutput sys$pipe " ORA_DBA "

%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation


If I just issue first part I have no error

$ pipe/trusted show process/rights
output ok

I enabled auditing:
$ set audit/enable=priv=failure=all/alarm
And got:

%%%%%%%%%%% OPCOM 30-JUL-2007 11:14:32.21 %%%%%%%%%%%
Message from user AUDIT$SERVER on PM3
Security alarm (SECURITY) on PM3, system id: 2051
Auditable event: Privilege failure
Event information: GRPNAM not used to bypass discretionary access to a logical name table
Event time: 30-JUL-2007 11:14:32.21
PID: 23FEB94E
Process name: MAZZINI ²BATCH
Username: A038ADSI01
Process owner: [A038ADSI01]
Logical name table name: LNM$GROUP_002016
Privileges missing: GRPNAM
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)

Clear from this what privilege is missing, not sure what to do.

Does this happen to you on Vms 7.3-2?

Thanks

[Volker Halle]

Miguel,

PIPE is not supposed to create a logical in the LNM$GROUP table, it's supposed to create the SYS$PIPE logical in the process table.

Try $ pipe dir | sho log sys$pipe/full

Volker.

[Jan van den Ende]

Miguel,

>>>Event information: GRPNAM not used to bypass discretionary access to a logical name table
.
.
.
Logical name table name: LNM$GROUP_002016
<<<

So, you are not allowed to access the logical name table of group [2016,*].

During a command that creates a subprocess, and communicates with it by temporary mailbox.

This implies that you(r process have done
$ define lnm$temporary_mailbox lnm$group /table=lnm$processdirectory

And since you explicitly switched OFF privileges on both versions, the access you need will be via the GROUP protection mask, or an explicit ACL entry.

On both systems, do a
$ show security/object_type=name_table LNM$GROUP

Compare the results, and the reason will become obvious.

hth

Proost.

Have one on me.

jpe

[Jan van den Ende]

>>>
This implies that you(r process have done
<<<

a rather vital ")" got lost.

It should read
This implies that you(r process) have done

And the command that creates the subprocess, I should have made explicit that this is PIPE

Proost.

Have one on me.

jpe

[Miguel Ward]

Thanks for replies.

With grpnam privilege I get for following command:

$ pipe dir | sho log sys$pipe/full
"SYS$PIPE" [super] = "_PM3$MPA6259:" [terminal] (LNM$PROCESS_TABLE)

Now if I run without GRPNAM privilege I get
$ pipe dir | sho log sys$pipe/full
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

As you state the sys$pipe is created in the process table but it would seem there is some prior checking against the group table which is what causes the error.

Other command on both 732 and 83 returns the same:

$ show security LNM$GROUP_002016 /class=logical_name_table

LNM$GROUP_002016 object of class LOGICAL_NAME_TABLE
Owner: [2016,*]
Protection: (System: RWCD, Owner: R, Group: R, World)
Access Control List:

Do you see anything wrong here?

I assume you don't have 732 running to reproduce error.

Thanks

[Hoff]

>>>The 'real' command Oracle procedures are issuing is:

$ pipe/trusted show process/rights | search/nowarn/nooutput sys$pipe " ORA_DBA "

%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation<<<<


Contact whoever is supporting this code, and have them look at it. Suggest that they switch to f$getjpi with the PROCESS_RIGHTS itemcode, too.

There were some fixes around spawned subprocesses and identifiers, and I don't know if these were rolled out as an ECO kit, or were built into subsequent OpenVMS releases.

There have also been problems around applications that have been performing SET UIC and similar commands; when the spawned subprocess cannot access one of the core mailboxes.

Again, if you have the ECO kits Oracle says you need, punt this to Oracle for a look. And I'd replace this construct with one that checks for the identifier. (The SEARCH-based approach used here would erroneously pass the test if any substring anywhere in the response matches the target, whether or not the actual identifier is involved in that string.)

Put another way, there may well be a bug in OpenVMS here, but there's definitely also a bug in Oracle here. If this is your code or if it is Oracle code, well, I'd suggest switching to the lexical function.

As for the group name stuff, you're either not in the same group -- somebody has been messing with the logical name translation for the group logical name table, or the table is protected against access. When you turn off GRPNAM, then the process cannot access the table. Which means either OpenVMS changed here, or you have a different configuration on the group tables on V7.3-2 and on the V8.3 system. I've also seen this case crop up when somebody has been working with WHEEL or SET UIC or GLOGIN or HGLOGIN or such; when somebody has been swapping UICs on the running process.

Stephen Hoffman
HoffmanLabs LLC



And in either and any case, this PIPE-based command sequence is itself busted.

[John Gillings]

Miguel,

I have a V7.3-2 system and cannot reproduce the error you describe.

Can you please check the state of the group table. Try:

$ SHOW LOG/FULL/TABLE=LNM$GROUP_002016

I'd also like to see the output of:

$ SHOW LOGICAL/FULL/TABLE=LNM$PROCESS_DIRECTORY *

[Volker Halle]

Miguel,

I can somehow reproduce this NOPRIV error (on V8.3), if I change lnm$temporary_mailbox

$ define lnm$temporary_mailbox lnm$group /table=lnm$process_directory
$ pipe dir | sho log sys$pipe/full
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
$ deass lnm$temporary_mailbox/table=lnm$process_directory
$ pipe dir | sho log sys$pipe/full
"SYS$PIPE" [super] = "_AXPVMS$MPA69:" [terminal] (LNM$PROCESS_TABLE)

Did you check this logical on your system ?

$ sho log lnm$temporary_mailbox/table=*

Volker.

[Miguel Ward]

Once again thank you all for your help which led me to find the problem which had nothing to do with Vms version.

The user in question had defined in his login.com

DEFINE/NOLOG/TABLE=lnm$process_directory lnm$temporary_mailbox lnm$group

I definitely missed this, the user has no idea why/when he put this in (login.com is dated 2006) and obviously there was nothing else affected by this definition.

In my testing at one stage I had used the JUMP command to change users and this caused additional confussion (as per Hoffman's comment). On vms 83 this user did not exist so created from zero to test with no login.com.

Anyway, all excuses on my behalf...

Sorry to have not seen this mistake before.

Thanks

Miguel from Patagonia Argentina