09-15-2011 02:05 AM
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.
Solved! Go to Solution.
09-15-2011 02:09 AM
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...
09-15-2011 02:17 AM
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.
09-15-2011 03:35 AM
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.
09-15-2011 05:13 AM
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.
09-15-2011 05:30 AM - edited 09-15-2011 05:54 AM
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...
09-15-2011 05:39 AM - edited 09-15-2011 05:39 AM
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.
09-15-2011 05:56 AM
then you have to turn on individual privs - one at a time- under SYSTEM, until the mount works (starting with only SYSNAM,TMPMBX,NETMBX).
09-15-2011 06:11 AM
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?
09-15-2011 06:23 AM - edited 09-15-2011 06:34 AM
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).
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.
09-15-2011 06:40 AM - edited 09-15-2011 06:50 AM
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
Process name: _TNA17:
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.
09-15-2011 06:51 AM
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.
09-15-2011 06:54 AM - edited 09-15-2011 06:58 AM
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
01-30-2012 03:42 AM
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.
03-19-2012 01:19 AM
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.