Bug 462275

+++ This bug was initially created as a clone of Bug #458252 +++

Created an attachment (id=313676)
Patch to raise the limit of number of local interfaces handled.

Description of problem:

  If you have more than 3 network interfaces on a machine, automount can fail
  to recognize that a "remote" host is actually the local host.



Version-Release number of selected component (if applicable):

  5.0.1-0.rc2.88



How reproducible:

  Very.


Steps to Reproduce:

  1. Configure multiple interfaces on a machine with IP addresses.  We
     used tagged ethernet instead of multiple physical interfaces, but it
     should be triggered by any kinds of interfaces.  On x86_64 you need
     at least four interfaces (haven't checked if the same limit applies
     to other architectures).

  2. Create an automount map that wants to NFS mount a directory on the
     same machine, referring to one of the later IP addresses of the
     machine (I think the order that 'ip addr show' displays them in is
     the one you should look at).  We used a direct map, saying
	  /pkg          -fstype=nfs     s1:/export/pkg
     where 's1' was the fourth IPv4 address shown by 'ip addr show'.

  3. NFS export the filesystem (/export/pkg in the above example).

  4. Start autofs.

  5. Access something below the mountpoint (/pkg in our case).

  6. Run 'mount | grep /pkg', and see how it mounted /pkg.


  
Actual results:

  Automount used NFS to mount /pkg from the local host.



Expected results:

  Automount should have created a bind mount.



Additional info:

  The problem is that automount passes a too small buffer to the
  SIOCGIFCONF ioctl when it tries to see what addresses the machine
  it is running on has.  The buffer is only 128 bytes long, and each
  struct ifreq is 40 bytes, so the buffer only fits three interfaces.
  That's *way* to little.

  This is in the function get_proximity() in modules/replicated.c.

  I am attaching a patch that uses a buffer that is MAX_IFC_BUF bytes,
  instead of MAX_ERR_BUF bytes.  It doesn't really solve the problem,
  just moves the limit to 51 interfaces, from 3 interfaces.  I have only
  had time to test it very lightly, though.

  A better solution would be to dynamically allocate a buffer, making
  sure to never miss any interfaces.  Something like allocating a
  buffer with malloc(), do a SIOCGIFCONF, check that the used part of
  the buffer is at least sizeof(struct ifreq) smaller than the buffer,
  and if not make the buffer larger and try again.  But I don't have the
  time to make such a patch right now; I'm leaving for vacation tomorrow
  and won't be back for four weeks.

  This problem seems to still exists in autofs 5.0.3 with all patches
  downloaded from http://www.kernel.org/pub/linux/daemons/autofs/v5/.
  (I have only made a visual check of the 5.0.3 source code, though; I
  haven't actually tested that version.)

--- Additional comment from ikent on 2008-08-07 07:19:31 EDT ---

>   The problem is that automount passes a too small buffer to the
>   SIOCGIFCONF ioctl when it tries to see what addresses the machine
>   it is running on has.  The buffer is only 128 bytes long, and each
>   struct ifreq is 40 bytes, so the buffer only fits three interfaces.
>   That's *way* to little.

Yep, your right.

> 
>   This is in the function get_proximity() in modules/replicated.c.
> 
>   I am attaching a patch that uses a buffer that is MAX_IFC_BUF bytes,
>   instead of MAX_ERR_BUF bytes.  It doesn't really solve the problem,
>   just moves the limit to 51 interfaces, from 3 interfaces.  I have only
>   had time to test it very lightly, though.

Yep, that sound much better.

> 
>   A better solution would be to dynamically allocate a buffer, making
>   sure to never miss any interfaces.  Something like allocating a
>   buffer with malloc(), do a SIOCGIFCONF, check that the used part of
>   the buffer is at least sizeof(struct ifreq) smaller than the buffer,
>   and if not make the buffer larger and try again.  But I don't have the
>   time to make such a patch right now; I'm leaving for vacation tomorrow
>   and won't be back for four weeks.

That would be good but I'm not sure I'll be able to do this in
time for 5.3.

> 
>   This problem seems to still exists in autofs 5.0.3 with all patches
>   downloaded from http://www.kernel.org/pub/linux/daemons/autofs/v5/.
>   (I have only made a visual check of the 5.0.3 source code, though; I
>   haven't actually tested that version.)

No need to check further that's also true.

Ian

--- Additional comment from pm-rhel on 2008-08-07 07:32:17 EDT ---

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.