| 2022-06-06 13:37:57 |
Marcel |
bug |
|
|
added bug |
| 2022-06-08 16:52:35 |
Marcel |
attachment added |
|
cifs-utils/svcgssd: Display principal if set https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1977745/+attachment/5595660/+files/02-nfs-utils-log-principal.patch |
|
| 2022-06-08 16:53:43 |
Marcel |
attachment added |
|
cifs-utils/svcgssd: Fix use-after-free bug (config variables) https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1977745/+attachment/5595661/+files/01-nfs-utils-fix-conf.patch |
|
| 2022-06-08 20:28:47 |
Ubuntu Foundations Team Bug Bot |
tags |
nfs-kernel-server nfs-utils nfs.conf |
nfs-kernel-server nfs-utils nfs.conf patch |
|
| 2022-06-08 20:28:56 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2022-06-24 19:38:47 |
Andreas Hasenack |
nfs-utils (Ubuntu): status |
New |
Incomplete |
|
| 2022-06-24 19:38:49 |
Andreas Hasenack |
nfs-utils (Ubuntu): status |
Incomplete |
In Progress |
|
| 2022-06-24 19:38:54 |
Andreas Hasenack |
nfs-utils (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-06-24 19:39:04 |
Andreas Hasenack |
tags |
nfs-kernel-server nfs-utils nfs.conf patch |
nfs-kernel-server nfs-utils nfs.conf patch server-todo |
|
| 2022-06-24 19:39:12 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-06-24 19:39:19 |
Andreas Hasenack |
bug |
|
|
added subscriber Canonical Server |
| 2022-06-27 17:07:39 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-06-27 17:07:39 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Ubuntu Jammy) |
|
| 2022-06-27 17:07:39 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Kinetic |
|
| 2022-06-27 17:07:39 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Ubuntu Kinetic) |
|
| 2022-06-27 17:07:56 |
Andreas Hasenack |
nfs-utils (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-06-27 17:08:01 |
Andreas Hasenack |
nfs-utils (Ubuntu Jammy): status |
New |
Triaged |
|
| 2022-06-27 17:08:04 |
Andreas Hasenack |
nfs-utils (Ubuntu Kinetic): importance |
Undecided |
Low |
|
| 2022-06-27 17:08:05 |
Andreas Hasenack |
nfs-utils (Ubuntu Jammy): importance |
Undecided |
Low |
|
| 2022-06-27 20:51:21 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/425667 |
|
| 2022-06-30 10:04:31 |
Launchpad Janitor |
nfs-utils (Ubuntu Kinetic): status |
In Progress |
Fix Released |
|
| 2022-08-03 12:40:08 |
Andreas Hasenack |
nfs-utils (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2022-08-03 13:16:02 |
Andreas Hasenack |
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@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. |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[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@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. |
|
| 2022-08-03 13:32:11 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[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@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. |
[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 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.
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@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. |
|
| 2022-08-03 13:40:10 |
Andreas Hasenack |
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 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.
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@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. |
[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@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. |
|
| 2022-08-03 14:30:25 |
Andreas Hasenack |
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@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. |
[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]
Create a jammy vm. For example, with lxd:
$ lxc launch ubuntu:jammy j-nfs-1977745 --vm
Then login on the sytstem:
$ lxc shell j-nfs-1977745
Install a kerberos kdc, utilities, and nfs server packages:
# apt update && apt install -y krb5-kdc krb5-admin-server nfs-kernel-server
Above, when prompted for the realm and KDC/ADMIN servers, use SRU for the realm, and "localhost" for the kdc and admin servers.
Now create the realm. Choose whatever password you like, it won't be needed again:
# krb5_newrealm
Create a service principal for the nfs server. To test this bug, we will create a principal with a non-standard name:
# kadmin.local -q "addprinc -randkey someservice/somehost@SRU"
Extract it to the system keytab:
# kadmin.local -q "ktadd someservice/somehost@SRU"
Stop nfs services, just to be sure they are not running for the subsequent tests:
# systemctl stop nfs-utils.service nfs-server.service
Now the tests begin.
a) In the released version, the nfs.conf(5) manpage only lists the "principal" option under "svcgssd":
"""
svcgssd
Recognized values: principal.
See rpc.svcgssd(8) for details.
"""
The fixed version will add to that list verbosity, rpc-verbosity, and idmap-vervosity:
"""
svcgssd
Recognized values: principal, verbosity, rpc-verbosity, idmap-verbosity.
"""
b) Set the specific principal we created for svcgssd in /etc/nfs.conf:
# nfsconf --set svcgssd principal someservice/somehost@SRU
Confirm it's there:
# grep principal /etc/nfs.conf -B 1
[svcgssd]
principal = someservice/somehost@SRU
Run the svcgssd binary, and confirm it fails and complains about missing credentials:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for @SRU
unable to obtain root (machine) credentials
do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
In the fixed version, it will start normally:
# /usr/sbin/rpc.svcgssd -f
(no further output)
c) In the error case from (b), note that it suggest to check for a generic principal name in the keytab, without mentioning the specific principal we set in nfs.conf.
For the fixed version, let's change the principal name to one we really don't have a keytab for, and see what the error message suggests this time:
# nfsconf --set svcgssd principal anotherservice/anotherhost@SRU
This time the error specifically mentions anotherservice/anotherhost@SRU instead of the generic nfs/<your.host>@<YOUR.REALM>:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for anotherservice/anotherhost@SRU
unable to obtain root (machine) credentials
do you have a keytab entry for anotherservice/anotherhost@SRU in/etc/krb5.keytab?
[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@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. |
|
| 2022-08-03 14:31:33 |
Andreas Hasenack |
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]
Create a jammy vm. For example, with lxd:
$ lxc launch ubuntu:jammy j-nfs-1977745 --vm
Then login on the sytstem:
$ lxc shell j-nfs-1977745
Install a kerberos kdc, utilities, and nfs server packages:
# apt update && apt install -y krb5-kdc krb5-admin-server nfs-kernel-server
Above, when prompted for the realm and KDC/ADMIN servers, use SRU for the realm, and "localhost" for the kdc and admin servers.
Now create the realm. Choose whatever password you like, it won't be needed again:
# krb5_newrealm
Create a service principal for the nfs server. To test this bug, we will create a principal with a non-standard name:
# kadmin.local -q "addprinc -randkey someservice/somehost@SRU"
Extract it to the system keytab:
# kadmin.local -q "ktadd someservice/somehost@SRU"
Stop nfs services, just to be sure they are not running for the subsequent tests:
# systemctl stop nfs-utils.service nfs-server.service
Now the tests begin.
a) In the released version, the nfs.conf(5) manpage only lists the "principal" option under "svcgssd":
"""
svcgssd
Recognized values: principal.
See rpc.svcgssd(8) for details.
"""
The fixed version will add to that list verbosity, rpc-verbosity, and idmap-vervosity:
"""
svcgssd
Recognized values: principal, verbosity, rpc-verbosity, idmap-verbosity.
"""
b) Set the specific principal we created for svcgssd in /etc/nfs.conf:
# nfsconf --set svcgssd principal someservice/somehost@SRU
Confirm it's there:
# grep principal /etc/nfs.conf -B 1
[svcgssd]
principal = someservice/somehost@SRU
Run the svcgssd binary, and confirm it fails and complains about missing credentials:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for @SRU
unable to obtain root (machine) credentials
do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
In the fixed version, it will start normally:
# /usr/sbin/rpc.svcgssd -f
(no further output)
c) In the error case from (b), note that it suggest to check for a generic principal name in the keytab, without mentioning the specific principal we set in nfs.conf.
For the fixed version, let's change the principal name to one we really don't have a keytab for, and see what the error message suggests this time:
# nfsconf --set svcgssd principal anotherservice/anotherhost@SRU
This time the error specifically mentions anotherservice/anotherhost@SRU instead of the generic nfs/<your.host>@<YOUR.REALM>:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for anotherservice/anotherhost@SRU
unable to obtain root (machine) credentials
do you have a keytab entry for anotherservice/anotherhost@SRU in/etc/krb5.keytab?
[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@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. |
[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]
Create a jammy vm. For example, with lxd:
$ lxc launch ubuntu:jammy j-nfs-1977745 --vm
Then login on the sytstem:
$ lxc shell j-nfs-1977745
Install a kerberos kdc, utilities, and nfs server packages:
# apt update && apt install -y krb5-kdc krb5-admin-server nfs-kernel-server
Above, when prompted for the realm and KDC/ADMIN servers, use SRU for the realm, and "localhost" for the kdc and admin servers.
Now create the realm. Choose whatever password you like, it won't be needed again:
# krb5_newrealm
Create a service principal for the nfs server. To test this bug, we will create a principal with a non-standard name:
# kadmin.local -q "addprinc -randkey someservice/somehost@SRU"
Extract it to the system keytab:
# kadmin.local -q "ktadd someservice/somehost@SRU"
Stop nfs services, just to be sure they are not running for the subsequent tests:
# systemctl stop nfs-utils.service nfs-server.service
Now the tests begin.
a) In the released version, the nfs.conf(5) manpage only lists the "principal" option under "svcgssd":
"""
svcgssd
Recognized values: principal.
See rpc.svcgssd(8) for details.
"""
The fixed version will add to that list verbosity, rpc-verbosity, and idmap-vervosity:
"""
svcgssd
Recognized values: principal, verbosity, rpc-verbosity, idmap-verbosity.
"""
b) Set the specific principal we created for svcgssd in /etc/nfs.conf:
# nfsconf --set svcgssd principal someservice/somehost@SRU
Confirm it's there:
# grep principal /etc/nfs.conf -B 1
[svcgssd]
principal = someservice/somehost@SRU
Run the svcgssd binary, and confirm it fails and complains about missing credentials:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for @SRU
unable to obtain root (machine) credentials
do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
In the fixed version, it will start normally:
# /usr/sbin/rpc.svcgssd -f
(no further output)
c) In the error case from (b), note that it suggests to check for a generic principal name in the keytab, without mentioning the specific principal we set in nfs.conf.
For the fixed version, let's change the principal name to one we really don't have a keytab for, and see what the error message suggests this time:
# nfsconf --set svcgssd principal anotherservice/anotherhost@SRU
This time the error specifically mentions anotherservice/anotherhost@SRU instead of the generic nfs/<your.host>@<YOUR.REALM>:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for anotherservice/anotherhost@SRU
unable to obtain root (machine) credentials
do you have a keytab entry for anotherservice/anotherhost@SRU in/etc/krb5.keytab?
[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@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. |
|
| 2022-08-03 14:36:37 |
Andreas Hasenack |
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]
Create a jammy vm. For example, with lxd:
$ lxc launch ubuntu:jammy j-nfs-1977745 --vm
Then login on the sytstem:
$ lxc shell j-nfs-1977745
Install a kerberos kdc, utilities, and nfs server packages:
# apt update && apt install -y krb5-kdc krb5-admin-server nfs-kernel-server
Above, when prompted for the realm and KDC/ADMIN servers, use SRU for the realm, and "localhost" for the kdc and admin servers.
Now create the realm. Choose whatever password you like, it won't be needed again:
# krb5_newrealm
Create a service principal for the nfs server. To test this bug, we will create a principal with a non-standard name:
# kadmin.local -q "addprinc -randkey someservice/somehost@SRU"
Extract it to the system keytab:
# kadmin.local -q "ktadd someservice/somehost@SRU"
Stop nfs services, just to be sure they are not running for the subsequent tests:
# systemctl stop nfs-utils.service nfs-server.service
Now the tests begin.
a) In the released version, the nfs.conf(5) manpage only lists the "principal" option under "svcgssd":
"""
svcgssd
Recognized values: principal.
See rpc.svcgssd(8) for details.
"""
The fixed version will add to that list verbosity, rpc-verbosity, and idmap-vervosity:
"""
svcgssd
Recognized values: principal, verbosity, rpc-verbosity, idmap-verbosity.
"""
b) Set the specific principal we created for svcgssd in /etc/nfs.conf:
# nfsconf --set svcgssd principal someservice/somehost@SRU
Confirm it's there:
# grep principal /etc/nfs.conf -B 1
[svcgssd]
principal = someservice/somehost@SRU
Run the svcgssd binary, and confirm it fails and complains about missing credentials:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for @SRU
unable to obtain root (machine) credentials
do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
In the fixed version, it will start normally:
# /usr/sbin/rpc.svcgssd -f
(no further output)
c) In the error case from (b), note that it suggests to check for a generic principal name in the keytab, without mentioning the specific principal we set in nfs.conf.
For the fixed version, let's change the principal name to one we really don't have a keytab for, and see what the error message suggests this time:
# nfsconf --set svcgssd principal anotherservice/anotherhost@SRU
This time the error specifically mentions anotherservice/anotherhost@SRU instead of the generic nfs/<your.host>@<YOUR.REALM>:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for anotherservice/anotherhost@SRU
unable to obtain root (machine) credentials
do you have a keytab entry for anotherservice/anotherhost@SRU in/etc/krb5.keytab?
[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@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. |
[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]
Create a jammy vm. For example, with lxd:
$ lxc launch ubuntu:jammy j-nfs-1977745 --vm
Then login on the sytstem:
$ lxc shell j-nfs-1977745
Install a kerberos kdc, utilities, and nfs server packages:
# apt update && apt install -y krb5-kdc krb5-admin-server nfs-kernel-server
Above, when prompted for the realm and KDC/ADMIN servers, use SRU for the realm, and "localhost" for the kdc and admin servers.
Now create the realm. Choose whatever password you like, it won't be needed again:
# krb5_newrealm
Create a service principal for the nfs server. To test this bug, we will create a principal with a non-standard name:
# kadmin.local -q "addprinc -randkey someservice/somehost@SRU"
Extract it to the system keytab:
# kadmin.local -q "ktadd someservice/somehost@SRU"
Stop nfs services, just to be sure they are not running for the subsequent tests:
# systemctl stop nfs-utils.service nfs-server.service
Now the tests begin.
a) In the released version, the nfs.conf(5) manpage only lists the "principal" option under "svcgssd":
"""
svcgssd
Recognized values: principal.
See rpc.svcgssd(8) for details.
"""
The fixed version will add to that list verbosity, rpc-verbosity, and idmap-vervosity:
"""
svcgssd
Recognized values: principal, verbosity, rpc-verbosity, idmap-verbosity.
"""
b) Set the specific principal we created for svcgssd in /etc/nfs.conf:
# nfsconf --set svcgssd principal someservice/somehost@SRU
Confirm it's there:
# grep principal /etc/nfs.conf -B 1
[svcgssd]
principal = someservice/somehost@SRU
Run the svcgssd binary, and confirm it fails and complains about missing credentials:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for @SRU
unable to obtain root (machine) credentials
do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
In the fixed version, it will start normally:
# /usr/sbin/rpc.svcgssd -f
(no further output)
c) In the error case from (b), note that it suggests to check for a generic principal name in the keytab, without mentioning the specific principal we set in nfs.conf.
For the fixed version, let's change the principal name to one we really don't have a keytab for, and see what the error message suggests this time:
# nfsconf --set svcgssd principal anotherservice/anotherhost@SRU
This time the error specifically mentions anotherservice/anotherhost@SRU instead of the generic nfs/<your.host>@<YOUR.REALM>:
# /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_NO_CRED (No credentials were supplied, or the credentials were unavailable or inaccessible) - No key table entry found for anotherservice/anotherhost@SRU
unable to obtain root (machine) credentials
do you have a keytab entry for anotherservice/anotherhost@SRU in/etc/krb5.keytab?
[Where problems could occur]
An NFS server is actually comprised of multiple services, specially when kerberos is involved. Restarting them in the correct order is the goal of the packaging, but there are some cases where this doesn't yet work correctly, like bug #1971935 shows.
[Other Info]
Not at this time.
[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@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. |
|
| 2022-08-03 14:58:13 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/427771 |
|
| 2022-08-24 15:16:31 |
Andreas Hasenack |
tags |
nfs-kernel-server nfs-utils nfs.conf patch server-todo |
nfs-kernel-server nfs-utils nfs.conf patch |
|
| 2022-09-21 14:48:04 |
Robie Basak |
nfs-utils (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-09-21 14:48:06 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-09-21 14:48:07 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2022-09-21 14:48:10 |
Robie Basak |
tags |
nfs-kernel-server nfs-utils nfs.conf patch |
nfs-kernel-server nfs-utils nfs.conf patch verification-needed verification-needed-jammy |
|
| 2022-09-23 20:32:38 |
Andreas Hasenack |
tags |
nfs-kernel-server nfs-utils nfs.conf patch verification-needed verification-needed-jammy |
nfs-kernel-server nfs-utils nfs.conf patch verification-done-jammy verification-needed |
|
| 2022-10-05 03:48:30 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-10-05 03:49:06 |
Launchpad Janitor |
nfs-utils (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-02-19 19:20:53 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/437544 |
|
| 2023-02-20 00:03:01 |
Andreas Hasenack |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/437544 |
|
|
| 2023-08-07 23:55:26 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/448654 |
|
| 2023-08-08 02:27:50 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/448656 |
|
| 2023-08-08 02:28:08 |
Vladimir Petko |
merge proposal unlinked |
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/448656 |
|
|
| 2023-08-08 02:57:56 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/448656 |
|
| 2023-08-08 02:58:19 |
Vladimir Petko |
merge proposal unlinked |
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/448656 |
|
|
| 2024-02-27 02:03:52 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461312 |
|
| 2024-02-27 02:05:30 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461313 |
|
| 2024-02-27 02:06:21 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
| 2024-02-27 02:06:54 |
Vladimir Petko |
merge proposal unlinked |
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
|
| 2024-02-28 20:47:40 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
| 2024-02-28 21:46:31 |
Vladimir Petko |
merge proposal unlinked |
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
|
| 2024-02-29 02:49:13 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
| 2024-02-29 03:40:59 |
Vladimir Petko |
merge proposal unlinked |
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
|
| 2024-02-29 19:47:37 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~vpa1977/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/461314 |
|
