This issue was found while trying to setup additional regression slaves in jenkins. The regression slaves had multiple networks attached to them, one of which also had an IPv6 address. Failures were observed in tests 19-20 of tests/bugs/bug-904300.t in the glusterfs regression test suite. These tests were a part of testing nfs subdir authentication with hostnames. The nfs authentication function, mnt3_verify_auth, doesn't check with all the available addresses for a hostname during its check. This check has the following algorithm. (The client address is provided as a sockaddr_in type, client_addr) - Iterate over the list of allowed addresses for the subdir. For each address in the list do the following. - Perform a getaddrinfo on the address, which returns a struct addrinfo - If the family of the struct addrinfo is AF_INET (ipv4) - compare client_addr with addrinfo. - If compare succeeds, allow client else reject The above algorithm will fail with multiple networks or when using IPv6 networks as, 1. The comparision is not even done for IPv6 networks 2. The comparision is only done for the first addrinfo returned by getaddrinfo. In case of multi homed, multi protocol networks are associated with and address, getaddrinfo returns a list of addrinfo structs. The comparision needs to be done for all addrinfos in the list.
(In reply to Kaushal from comment #0) > This issue was found while trying to setup additional regression slaves in > jenkins. > > The regression slaves had multiple networks attached to them, one of which > also had an IPv6 address. Failures were observed in tests 19-20 of > tests/bugs/bug-904300.t in the glusterfs regression test suite. These tests > were a part of testing nfs subdir authentication with hostnames. > > The nfs authentication function, mnt3_verify_auth, doesn't check with all > the available addresses for a hostname during its check. This check has the > following algorithm. > > (The client address is provided as a sockaddr_in type, client_addr) > - Iterate over the list of allowed addresses for the subdir. For each > address in the list do the following. > - Perform a getaddrinfo on the address, which returns a struct addrinfo > - If the family of the struct addrinfo is AF_INET (ipv4) > - compare client_addr with addrinfo. > - If compare succeeds, allow client else reject > > The above algorithm will fail with multiple networks or when using IPv6 > networks as, > 1. The comparision is not even done for IPv6 networks IPv6 was not part of the requirement. The problem was to test it in IPv6 network. I guess Gluster NFS is not fully IPv6 compliant, I may be wrong. > 2. The comparision is only done for the first addrinfo returned by > getaddrinfo. > In case of multi homed, multi protocol networks are associated with and > address, getaddrinfo returns a list of addrinfo structs. The comparision > needs to be done for all addrinfos in the list. Absolutely correct, this needs to be fixed. Thanks, Santosh
REVIEW: http://review.gluster.org/8048 (gNFS: Fix multi-homed m/c issue in NFS subdir auth) posted (#1) for review on master by Santosh Pradhan (spradhan)
REVIEW: http://review.gluster.org/8048 (gNFS: Fix multi-homed m/c issue in NFS subdir auth) posted (#2) for review on master by Santosh Pradhan (spradhan)
REVIEW: http://review.gluster.org/8048 (gNFS: Fix multi-homed m/c issue in NFS subdir auth) posted (#3) for review on master by Santosh Pradhan (spradhan)
COMMIT: http://review.gluster.org/8048 committed in master by Niels de Vos (ndevos) ------ commit d3f0de90d0c5166e63f5764d2f21703fd29ce976 Author: Santosh Kumar Pradhan <spradhan> Date: Fri Jun 6 12:22:04 2014 +0530 gNFS: Fix multi-homed m/c issue in NFS subdir auth NFS subdir authentication doesn't correctly handle multi-homed (host with multiple NIC having multiple IP addr) OR multi-protocol (IPv4 and IPv6) network addresses. When user/admin sets HOSTNAME in gluster CLI for NFS subdir auth, mnt3_verify_auth() routine does not iterate over all the resolved n/w addrs returned by getaddrinfo() n/w API. Instead, it just tests with the one returned first. 1. Iterate over all the n/w addrs (linked list) returned by getaddrinfo(). 2. Move the n/w mask calculation part to mnt3_export_fill_hostspec() instead of doing it in mnt3_verify_auth() i.e. calculating for each mount request. It does not change for MOUNT req. 3. Integrate "subnet support code rpc-auth.addr.<volname>.allow" and "NFS subdir auth code" to remove code duplication. Change-Id: I26b0def52c22cda35ca11766afca3df5fd4360bf BUG: 1102293 Signed-off-by: Santosh Kumar Pradhan <spradhan> Reviewed-on: http://review.gluster.org/8048 Reviewed-by: Rajesh Joseph <rjoseph> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Niels de Vos <ndevos>
A beta release for GlusterFS 3.6.0 has been released. Please verify if the release solves this bug report for you. In case the glusterfs-3.6.0beta1 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED. Packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update (possibly an "updates-testing" repository) infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-September/018836.html [2] http://supercolony.gluster.org/pipermail/gluster-users/
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.6.1, please reopen this bug report. glusterfs-3.6.1 has been announced [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-November/019410.html [2] http://supercolony.gluster.org/mailman/listinfo/gluster-users