[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