Comment 5 for bug 1331201

* Brian Murray [2014-06-25 18:54:46 -0000]:
> Sergio - could you provide a test case which is part of the Stable
> Release Update process so that we can get this fixed in 14.04?

Let me try. The problem manifested itself spontaneously in my production
environment so I'm not sure exactly which ingredients are required
and which are optional. The following is probably overspecified.

Prerequisites:
-- a Kerberos realm (EXAMPLE.ORG); my KDC runs Heimdal (slightly modified
from Debian wheezy) but I see no reason why this should matter here.
-- an NFS server host (server.example.org) with /etc/krb5.keytab containing
valid keys for <email address hidden>, package nfs-kernel-server
installed, a filesystem at /export/nfs and an entry for it in /etc/exports:
/export/nfs client.example.org(sec=krb5p,rw,root_squash,sync,no_subtree_check)
This server can but need not be running Ubuntu 14.04 (in my tests it was
running Debian wheezy).
-- an NFS client host (client.example.org) with autofs configured to automount
server.example.org:/export/nfs somewhere (say, on /srv/nfs), running
the version of rpc.gssd that is to be tested. Remember to include sec=krb5p
in the mount options. It is recommended to run rpc.gssd with a short timeout
(e.g., rpc.gssd -t 60) at least for the purposes of this test: the bug
manifests itself when rpc.gssd prepares a new GSS context for the kernel,
so it helps to force this to happen often. In my environment the client
has machine credentials in /etc/krb5.keytab
(<email address hidden>, <email address hidden>
and <email address hidden>) though this is probably overkill
for the purposes of this test. The problem should be reproducible with a
static mount (no autofs) as well but I haven't actually tried that.

Testing procedure:
1. Log in to client.example.org as a non-root user with a corresponding
principal in EXAMPLE.ORG.
2. Obtain a Kerberos TGT for this user, either as part of the login process
(pam_krb5) or interactively by running kinit.
3. Try to access the mountpoint of the NFS share (/srv/nfs). A simple
 ls /srv/nfs
should be enough. This is expected to succeed even when the bug is present;
if it doesn't, the setup must be incorrect.
4. Look for warning messages from rpc.gssd (as in the subject of this bug
report) in the client's syslog (or, if running rpc.gssd -f, on standard
error) triggered by the NFS activity at step 3. These messages should no
longer appear once the patch is applied.

I've glossed over the configuration of /etc/idmapd.conf since I expect it
should all work with default settings there.