Comment 7 for bug 591943

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

A little more detailed scenario for reproducing, assuming:

 - An NFS server (IP == 10.33.8.116 in this example)
 - A virt host (IP == 10.33.8.111 in this example)

On the NFS server setup an exported filesystem, with the 'secure' flag set and restricted to the IP subnet of the virt hosts

  # cat >> /etc/exports <<EOF
  /var/lib/libvirt/images/export 10.33.8.0/255.255.255.0(rw,no_root_squash,secure)
  EOF
  # exportfs -a -r -v

On the virtualization host, ensure the default virtual network is running

  # virsh net-list
  Name State Autostart
  -----------------------------------------
  default active yes

And that it is configured to do NAT

  # virsh net-dumpxml default | grep forward
  <forward mode='nat'/>

Pick any guest OS and make sure it is connected to the default virtual network.

eg its XML config (virsh dumpxml $GUESTNAME) should have a NIC configured to look like this

    <interface type='network'>
      <mac address='52:54:00:56:44:32'/>
      <source network='default'/>
      <model type='virtio'/>
    </interface>

Boot the guest (virsh start $GUESTNAME)

Now, login to the guest in any manner (ssh, virt-viewer, virsh console,etc).

Attempt to mount the NFS server. Due to the NAT flaw, it will succeed.

With the fixed NAT rules it should should fail in this message:

  # mount 10.33.8.116:/var/lib/libvirt/images/export /mnt -t nfs
  mount.nfs: access denied by server while mounting 10.33.8.116:/var/lib/libvirt/images/export

If the NFS server is then modified to set 'insecure' in /etc/exports, the mount should work again, because this disables source port checking.