[Bug 1977745] Re: nfs-utils/nfs-kernel-server (rpc.svcgssd) ignored /etc/nfs.conf settings

Andreas Hasenack 1977745 at bugs.launchpad.net
Wed Aug 3 13:32:11 UTC 2022


** Description changed:

  [Impact]
+ The "principal" option for svcgssd in /etc/nfs.conf is being ignored by the service. This breaks NFS setups that use kerberos and need a specific principal name.
  
-  * An explanation of the effects of the bug on users and
+ Another issue is that some svcgssd options are missing from its manpage,
+ notably verbosity, rpc-verbosity and idmap-verbosity, that on its own
+ probably wouldn't warrant an SRU, but can go together with this one. I
+ don't think a new bug is needed, since they are about svcgssd too.
  
-  * justification for backporting the fix to the stable release.
+ Finally, when using the "principal" option, it would be helpful if the
+ error message actually used the given principal name, instead of a
+ generic "nfs/<your.host>@<YOUR.REALM>" one. Again, on its own it does
+ not warrant an SRU, but can go together with this one.
  
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
+ The test case will cover all three issues.
+ 
  
  [Test Plan]
  
-  * detailed instructions how to reproduce the bug
+  * detailed instructions how to reproduce the bug
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package fixes
+    the problem.
  
-  * if other testing is appropriate to perform before landing this update,
-    this should also be described here.
+  * if other testing is appropriate to perform before landing this update,
+    this should also be described here.
  
  [Where problems could occur]
  
-  * Think about what the upload changes in the software. Imagine the change is
-    wrong or breaks something else: how would this show up?
+  * Think about what the upload changes in the software. Imagine the change is
+    wrong or breaks something else: how would this show up?
  
-  * It is assumed that any SRU candidate patch is well-tested before
-    upload and has a low overall risk of regression, but it's important
-    to make the effort to think about what ''could'' happen in the
-    event of a regression.
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what ''could'' happen in the
+    event of a regression.
  
-  * This must '''never''' be "None" or "Low", or entirely an argument as to why
-    your upload is low risk.
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+    your upload is low risk.
  
-  * This both shows the SRU team that the risks have been considered,
-    and provides guidance to testers in regression-testing the SRU.
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
-  * and address these questions in advance
  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
+  * and address these questions in advance
  
  [Original Description]
  
  Tested on:
   Ubuntu 22.04 (x86_64)
   Package: nfs-kernel-server 1:2.6.1-1ubuntu1
  
  Set config options in /etc/nfs.conf are ignored by rpc.svcgssd (required
  for krb5 NFSv4).
  
  I was trying to set the principal name like:
  
  [svcgssd]
  principal=nfs/myhost.mydomain.de at MYDOMAIN.DE
  
  but rpc.svcgssd refused to start. When specified on command line (using
  the -p option) things started working.
  
  After having a look at the code (nfs-utils-2.6.1/utils/gssd/svcgssd.c),
  the problem seems to be
  
          /* We don't need the config anymore */
          conf_cleanup();
  
  which is called too early. So at the point where gssd_acquire_cred() is
  called the variable "principal" does no longer contain the data read
  from the config file.
  
  Moving conf_cleanup() to the end of the code helps.
  
  I also tried to get into contact with the nfs-utils developer themselves
  - but I hope someone at Ubuntu has a better way to contact them.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1977745

Title:
  nfs-utils/nfs-kernel-server (rpc.svcgssd) ignored /etc/nfs.conf
  settings

Status in nfs-utils package in Ubuntu:
  Fix Released
Status in nfs-utils source package in Jammy:
  In Progress
Status in nfs-utils source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  The "principal" option for svcgssd in /etc/nfs.conf is being ignored by the service. This breaks NFS setups that use kerberos and need a specific principal name.

  Another issue is that some svcgssd options are missing from the
  nfs.conf(5) manpage, notably verbosity, rpc-verbosity and idmap-
  verbosity, that on its own probably wouldn't warrant an SRU, but can
  go together with this one. I don't think a new bug is needed, since
  they are about svcgssd too.

  Finally, when using the "principal" option, it would be helpful if the
  error message actually used the given principal name, instead of a
  generic "nfs/<your.host>@<YOUR.REALM>" one. Again, on its own it does
  not warrant an SRU, but can go together with this one.

  The test case will cover all three issues.

  [Test Plan]

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
     package to reproduce the bug and verify that the updated package fixes
     the problem.

   * if other testing is appropriate to perform before landing this update,
     this should also be described here.

  [Where problems could occur]

   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?

   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.

   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.

   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.

  [Other Info]

   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
   * and address these questions in advance

  [Original Description]

  Tested on:
   Ubuntu 22.04 (x86_64)
   Package: nfs-kernel-server 1:2.6.1-1ubuntu1

  Set config options in /etc/nfs.conf are ignored by rpc.svcgssd
  (required for krb5 NFSv4).

  I was trying to set the principal name like:

  [svcgssd]
  principal=nfs/myhost.mydomain.de at MYDOMAIN.DE

  but rpc.svcgssd refused to start. When specified on command line
  (using the -p option) things started working.

  After having a look at the code (nfs-
  utils-2.6.1/utils/gssd/svcgssd.c), the problem seems to be

          /* We don't need the config anymore */
          conf_cleanup();

  which is called too early. So at the point where gssd_acquire_cred()
  is called the variable "principal" does no longer contain the data
  read from the config file.

  Moving conf_cleanup() to the end of the code helps.

  I also tried to get into contact with the nfs-utils developer
  themselves - but I hope someone at Ubuntu has a better way to contact
  them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1977745/+subscriptions




More information about the foundations-bugs mailing list