rpc.gssd performs reverse DNS by default (regardless of -D flag)

Bug #1697339 reported by forceps on 2017-06-12
This bug affects 3 people
Affects Status Importance Assigned to Milestone
nfs-utils (Debian)
Fix Released
nfs-utils (Ubuntu)

Bug Description

Description: Ubuntu 16.04.2 LTS
Release: 16.04

Package: nfs-common 1:1.2.8-9ubuntu12.1.0

This bug affects all active and proposed versions of nfs-common used by ubuntu (as every version is based on nfs-utils_1.2.8) from trusty to artful.

There is a small error in the code for rpc.gssd that causes it to always perform reverse DNS when looking up the server name to pass to GSSAPI. This causes a problem for NFS4 in environments where reverse DNS is incorrectly configured or not configurable by the system administrator. This has been confirmed in Debian and a more recent version of nfs-utils that appears to have fixed this has been pushed to sid:

However, I do not know if that version of nfs-utils will make it to ubuntu soon. Will it?

If not, the patch to this appears to be rather straightforward.
The error is an '== 1' instead of an '== 0' in two lines of gssd_proc.c that are evaluated when the -D flag to rpc.gssd is not passed (and thus avoid_dns is true)

--- utils/gssd/gssd_proc.c 2017-06-11 15:47:35.000000000 -0700
+++ utils/gssd/gssd_proc_patch.c 2017-06-11 15:48:36.152115792 -0700
@@ -181,17 +181,17 @@
  if (avoid_dns) {
    * Determine if this is a server name, or an IP address.
    * If it is an IP address, do the DNS lookup otherwise
    * skip the DNS lookup.
   servername = 0;
- if (strchr(name, '.') && inet_pton(AF_INET, name, buf) == 1)
+ if (strchr(name, '.') && inet_pton(AF_INET, name, buf) == 0)
    servername = 1; /* IPv4 */
- else if (strchr(name, ':') && inet_pton(AF_INET6, name, buf) == 1)
+ else if (strchr(name, ':') && inet_pton(AF_INET6, name, buf) == 0)
    servername = 1; /* or IPv6 */

   if (servername) {
    return strdup(name);

Is there any way to get either 1) the updated version of nfs-utils or 2) this patch applied to xenial (and, hopefully, other versions of ubuntu)? Thank you for looking at this!

forceps (ubuntubugs-web) wrote :

The attachment "patch file of proposed fix (if necessary)" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
forceps (ubuntubugs-web) on 2017-06-13
description: updated
tags: added: xenial
Changed in nfs-utils (Debian):
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nfs-utils (Ubuntu):
status: New → Confirmed
Kevin Otte (nivex) wrote :

I just lost a good chunk of my evening to this. I'm using native IPv6 from my upstream ISP and therefore do not have control of rDNS. I was expecting the documented behavior and didn't realize I'd hit a bug until on a lark I added the IP address of the NFS server to the client's /etc/hosts file.

Ryan McGregor (rmcgregor) wrote :

Has there been any progress on getting this pushed to 16.04.4? If it's not going to be pushed to the public repos any time soon, is it available in a testing repo.

Kevin (kvasko) wrote :

I'm running into the same exact issue. Is there a workaround for this? My CentOS7.4 machines don't have this problem and I use a standard NFS mount script (with FQDN to mount all the shared directories on our systems). This requires me to have one for Ubuntu machines and one for CentOS.

TJ (tj) wrote :

There's a patch attached to the related Debian bug which works and is included in later packages.


Can we get this into 16.04 please?

Andreas Hasenack (ahasenack) wrote :

I'll take a look.

tags: added: server-next
Changed in nfs-utils (Ubuntu):
assignee: nobody → Andreas Hasenack (ahasenack)
Andreas Hasenack (ahasenack) wrote :

Fixed from bionic onwards.

Changed in nfs-utils (Ubuntu):
assignee: Andreas Hasenack (ahasenack) → nobody
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.