Privileges required for the NFS client under OpenVMS 8-4

[Brian Reiter]

Hi folks (again)

System is OpenVMS 8-4 (fully patched)

TCPIP 5-7 ECO 2

Remove NFS server is some kind of AIX host

What privileges are required for the MFS client running under OpenVMS? I can mount the shares quite happily from the system account, but from a user account I get the message

%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting DNFS1:
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

There is nothing obvious when I turn on auditing - nothing correlates to that error anyway. Assuming I can work out what privileges are reqired, would it be feasible to install the exes with the required privileges? If so which exes would need installing.

I'd rather not grant too many privilegs to the clients.

regards

Brian Reiter

[Volker Halle]

Brian,

did you check TCPIP SHOW PROXY ?

The NFS protocol works with TCPIP PROXIES, which (for outgoing access from the NFS client) map the OpenVMS Username to a gid/uid combination to be sent to the NFS server. If there are proxies for the SYSTEM account, but not for your user account, this may explain things...

Volker.

[Brian Reiter]

Hmmm,

Curious - the currently working system runs with priv=ALL  so that could explain it. So I'd need to add a proxy between this user and the root account on the remote system. There are no proxies existing at the moment, although the root one could be the default.

We're in the position of trying to get the system running within its own group, removing any access to system level constructs.

[Volker Halle]

Brian,

if there is a local privilege missing, TCPIP tends to explicitly show this missing privilege in the error message:

VAXVMS $ ucx mount dnfs1:/host=axpvms/path="/vms_nfs/nfs"         ! Example from UCX V4.2
%UCX$DNFSMOUNT-E-MOUNTFAIL, error mounting /vms_nfs/nfs
-SYSTEM-F-NOSYSNAM, operation requires SYSNAM privilege
 

So in your case, it looks like this is a privilege problem coming from the remote NFS server. Does the mount from SYSTEM work after SET PROC/PRIV=(NOALL,TMP,NET) ?

If no proxies are defined, the TCPIP client might be sending the default gid/uid pair, which could be -2/-2.

Volker.

[Brian Reiter]

Hi Volker,

The mount fails with privileges set to SYNAM,TMPMBX,NETMBX (using the sysem account). With no clues other than the initial request for SYSNAM as to which are needed. Setting up proxies for -2,-2 or 0,0 didn't help.

cheers

Brian

[Volker Halle]

Brian,

so you're saying that SYSTEM with privs set to only (SYSNAM,TMPMBX,NETMBX) fails to mount that remote NFS share, but SYSTEM with all privs works ? And the same mount command from the 'user' account also fails in the same way ? If so, you could try enabling privs for SYSTEM until it works...

But my gut feeling is, that the SYSTEM-F-NOPRIV error comes from the NFS server. Use TCPDUMP or TCPTRACE to check, whether the failing mount sends/receives any messages from the NFS server.

To determine the 'correct' proxy settings, you need to ask the system mgr of the remote NFS server node, which gid/uid it expects to allow access to the remote directory and files...

Volker.

[Brian Reiter]

Hi Volker.

I was in the middle of doing the TCPTRACE command. From the user account no traffic is seen at all, even though I get the standard error message. From the working system account plenty of traffic is seen.

cheers

Brian

[Volker Halle]

Brian,

then you have to turn on individual privs - one at a time- under SYSTEM, until the mount works (starting with only SYSNAM,TMPMBX,NETMBX).

Volker.

[Brian Reiter]

Hi Volker,

I had already started on that. It looks as though CMKRNL is the magic button in this case. Next question is, is there an easy way around this restriction? 

cheers

Brian

[Volker Halle · Accepted solution]

Brain,

this sounds like a bug - you may want to contact HP. There are newer NFS client images available beyond V5.7 ECO 2 (their ident should be V5.7-ECO2-22011).

Please see http://h30499.www3.hp.com/t5/Networking/NFS-v3-mount-to-directory-tree/m-p/4834519

Does TCPIP MOUNT/SHARE work ?

TCPIP$UCP.EXE should be installed with Privileges = CMKRNL PHY_IO anyway (check with INSTALL LIST/FULL SYS$SYSTEM:TCPIP$UCP). The mount code seems to be implemented in TCPIP$DNFS_MOUNT_SHR.EXE - a shareable library.

Volker.

[Brian Reiter]

Volker,

I had a quick look into TCPIP$STARTUP just to verify which privileges it was installed with, definitely CMKRNL and PHY_IO. The TCPIP$DNFS_MOUNT_SHR.EXE just seems to be installed with no privs (according to install list).

Security audit (SECURITY) on RCC01, system id: 1025
Auditable event:          Privilege failure
Event information:        CMKRNL not used to execute $CMKRNL(_64) system service ($CMKRNL or $CMKRNL_64)
Event time:               15-SEP-2011 14:11:37.80
PID:                      29202F35
Process name:             _TNA17:
Username:                 SIG_070_SYS
Process owner:            [RCC_070_SIG,SIG_070_SYS]
Terminal name:            TNA17:
Image name:               $20$DKA100:[SYS0.SYSCOMMON.][SYSEXE]TCPIP$UCP.EXE
Privileges missing:       CMKRNL
Posix UID:                -2
Posix GID:                -2 (%XFFFFFFFE)

From ANALYSE/AUDIT I get the above entry which seems odd given that it should be installed with CMKRNL.

(The forum has a censor? FFS! ).

Anyway, to answer your other question /SHARE doesn't work either, and I haven't got the later NFS images. Ah well, a call to HP when I am in a position to do so - i.e. if we buy any OpenVMS 8-4 systems I'll log the call on the back of the suppplied warranty.

[Volker Halle]

Brian,

you' re getting this event if the non-prived user tries to mount that NFS share, right ?

This would indicate, that some code in the TCPIP mount code path disabled CMKRNL and failed to re-enable it....

Raise a call to HP.

Volker.

[Brian Reiter]

Hi Volker,

Thanks for the help. I will log a call when I get a chance to. We don't generally have a support contract but we should be buying some OpenVMS 8-4 boxes soon so I may have a short warranty period to raise any calls.

And for those looking for the answer, for what its worth under OpenVMS 8-4, TCPIP 5-7 ECO2 you need CMKRNL in order to issue a TCPIP MOUNT

cheers

Brian

[Brian Reiter]

I have been told by HP that this issue has been fixed with TCPIP 5-7 ECO3 which waas released in December.

I will add an update once I have had a chance to repeat the experiment.

cheers

Brian

[John_Malmberg]

I installed TCPIP 5.7 ECO 3. The problem is still present.

I had to reinstall TCPIP 5.7 with no ECO in order to mount NFS disks.

[Brian Reiter]

Figures, I'll badger the Office of OpenVMS Programs and see if I can get a definitive response for when I may see a fix. Although I won't hold much hope of a response.

cheers

Brian