HP9000 Containers and NFS mounts

[JCI IT Unix]

I am running HP9000 Containers version A.03.01.  I have the container up and running.  I now need to mount an exported file system from another HPUX server with both read and write permissions.  I can get the mount okay but from the container I cannot read or write properly to the mounted file system.  The NFS server exporting the file system is running HPUX 11.31, here is the dfstab export line:

/usr/sbin/share -F nfs -o nosuid,rw,root=All,window=30000 -d "none" /var/adm/crash -

The container /etc/fstab entry is this:

j217uv01.corp.na.jci.com:/var/adm/crash /hpcontainer1 nfs soft,rw,nosuid 0 2

When logged into the container as root, I am able to touch a file.  The ownership of this file is odd.  It is:

-rw-r-----   1 -2         sys             21 Jun 22 14:31 stuff4

I would have expected the owner be root.  There are other files in this exported file system owned by root that from the container, root is unable to read.

Does anyone know what I need to change?

[Dennis Handly]

The UID of -2 means that "root is less than dirt".  Do you have this machine in your root=All netgroup?

[JCI IT Unix]

Your suggestion helped.  I did some digging and found that the NFS server authenticates root from the NFS client as nobody.  Not sure why.  I added "anon=0" to the /etc/dfs/dfstab on the NFS server.  This now has fixed the problem.  Not sure if it is the best way, but for now this allows root to read and write to the NFS mounted file system.  Thank you Dennis.

[Matti_Kurkela]

If root of the NFS client is not "less than dirt", an intruder who has managed to gain root access on one NFS client can easily get root access on the NFS server (and all the other NFS clients) too, by placing a suitable script or binary to the NFS share, giving it setuid root permissions and tricking someone (or something) on the server  to run it.

Since the intruder is root on the NFS client, he can write an executable to a writeable NFS share, set its ownership to root and permissions to e.g. 4755.

This is a very old attack plan for NFS environments. Every NFS server administrator should understand how it works, in order to correctly evaluate the need for countermeasures like the "the NFS client's root is less than dirt on the NFS server" setting.

[Dennis Handly]

>I added "anon=0"

My suggestion was for you to fix the root=, not necessarily the anon=.  Now any client root (or unknown) user can be root on the NFS filesystem.

[JCI IT Unix]

I did try the root=hostname alone prior to adding anon=0and that seemed to have no affect.

Currently my dfstab has the following:

/usr/sbin/share -F nfs -o nosuid,anon=0,rw,root=j217u019c3,window=30000 -d "none" /var/adm/crash -

It is only when I added "anon=0" that I was allowed to read files in the nfs mount file system as root on the nfs client.

[Dennis Handly]

>I did try the root=hostname alone prior to adding anon=0 and that seemed to have no affect.

>root=j217u019c3,

You may have to use FQDN and you may want to add to what you have: root=All,FQDN

[JCI IT Unix]

I made the change as follows on the NFS server dfstab:

/usr/sbin/share -F nfs -o nosuid,rw,root=j217u019c3.corp.na.jci.com,window=30000 -d "none" /var/adm/crash -

I took out "anon=0", added domain to hostname j217u019c3.

This has now allowed user root to read already existing files owned by root.  The ability to create a file by root is successful but the owner of the newly created file is again "-2" instead of "root".  User root cannot write to existing files owned by root.

[Dennis Handly]

>The ability to create a file by root is successful but the owner of the newly created file is again "-2" instead of "root".

Then root= isn't working.

Can you do: /usr/sbin/showmount -e -a name-of-server

Or do it on your server without the name.

Perhaps the name of your client isn't exactly what you have in root=?

[JCI IT Unix]

You have another BINGO.  The HP Container has two network cards configured as follows:

lan2:1    1500 10.11.5.0       10.11.5.63      63538338           0     47660597           0     0   
lan901:1  1500 10.11.16.128    10.11.16.138    277188             0     62253              0     0

The primary network for the container is lan901:1 (j217u019c3.corp.na.jci.com) which is an APA configuration, lan2:1 (j217u019b.corp.na.jci.com) is a tape backup network that is not an APA configuration.  I ran the showmount on the NFS server and it thinks the hostname for lan2:1 is what has mounted it.  In the dfstab, I replaced the primary hostname with the tape backup hostname, re-exported, re-mounted and now when I create a file it knows it is root that has created the file.  I can edit other root files in that NFS file system now as well.  I can leave it this way as it works but I can't help but wonder why it is doing this.