Hide Forgot
+++ This bug was initially created as a clone of Bug #697931 +++ +++ This bug was initially created as a clone of Bug #697928 +++ Description of problem: rpc.svcgssd Segmentation faults on "Wrong principal in request" Version-Release number of selected component (if applicable): nfs-utils-1.2.3-5 How reproducible: All the time. --- Additional comment from updates on 2011-04-20 08:44:47 EDT --- nfs-utils-1.2.3-11.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/nfs-utils-1.2.3-11.fc15
Created attachment 493488 [details] Proposed Patch
hi Steve, Could you tell me how did you trigger the issue?
(In reply to comment #8) > hi Steve, > Could you tell me how did you trigger the issue? The way I triggered this to have a F13 client, with a stale /etc/keytab, do a mount against a f15 server. This cause rpc.svcgssd to segfault and dump core. Once I figured out the problem, I quickly realized the problem was in f14, f15, and RHEL6. So in the end I never did reproduce the problem on RHEL6. Maybe one way to reproduce this is to create a /etc/keytab that does not have an DNS-able host name. They try a secure mount to a rhel6 server. If the error "Wrong principal in request" is logged, you know you have reproduced the problem.
(In reply to comment #9) > (In reply to comment #8) > > hi Steve, > > Could you tell me how did you trigger the issue? > The way I triggered this to have a F13 client, with a stale > /etc/keytab, do a mount against a f15 server. This cause > rpc.svcgssd to segfault and dump core. Once I figured > out the problem, I quickly realized the problem was > in f14, f15, and RHEL6. So in the end I never did > reproduce the problem on RHEL6. > > Maybe one way to reproduce this is to create > a /etc/keytab that does not have an DNS-able > host name. They try a secure mount to a rhel6 > server. If the error "Wrong principal in request" > is logged, you know you have reproduced the problem. hi Steve, Sorry, I still can't reproduce the problem. If I create a /etc/keytab that does not have an DNS-able host name, I will just got Permission denied of mount on client since No credentials created and found caused by the wrong entry in keytab (rpc.gssd[4406]: ERROR: No credentials found for connection to server...), so the client hadn't talked to rpc.svcgssd. So how do you let /etc/keytab stale? (comment nameserver in /etc/resolv.conf or get nfs/client@REALM credential first then remove the principal in kdc? All I do just got "Permission denied" on nfs client.) I test on the unpatch package nfs-utils-1.2.3-6.el6 on RHEL6.1: kdc: dell-pe1855-01.rhts.eng.bos.redhat.com nfs server: hp-xw6400-02.lab.bos.redhat.com nfs client: dell-pesc1425-02.rhts.eng.bos.redhat.com I will be appreciative if you could help me to check more.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > hi Steve, > > > Could you tell me how did you trigger the issue? > > The way I triggered this to have a F13 client, with a stale > > /etc/keytab, do a mount against a f15 server. This cause > > rpc.svcgssd to segfault and dump core. Once I figured > > out the problem, I quickly realized the problem was > > in f14, f15, and RHEL6. So in the end I never did > > reproduce the problem on RHEL6. > > > > Maybe one way to reproduce this is to create > > a /etc/keytab that does not have an DNS-able > > host name. They try a secure mount to a rhel6 > > server. If the error "Wrong principal in request" > > is logged, you know you have reproduced the problem. > > hi Steve, > Sorry, I still can't reproduce the problem. > If I create a /etc/keytab that does not have an DNS-able host name, I will just > got Permission denied of mount on client since No credentials created and found > caused by the wrong entry in keytab (rpc.gssd[4406]: ERROR: No credentials > found for connection to server...), so the client hadn't talked to rpc.svcgssd. > > So how do you let /etc/keytab stale? (comment nameserver in /etc/resolv.conf or > get nfs/client@REALM credential first then remove the principal in kdc? All I > do just got "Permission denied" on nfs client.) > > I test on the unpatch package nfs-utils-1.2.3-6.el6 on RHEL6.1: > kdc: dell-pe1855-01.rhts.eng.bos.redhat.com > nfs server: hp-xw6400-02.lab.bos.redhat.com > nfs client: dell-pesc1425-02.rhts.eng.bos.redhat.com > > I will be appreciative if you could help me to check more. Hmm... I wonder if the krb5 libraries are different on F15 than RHEL6... Like I said I was only able to reproduce the problem with F15... Since the fix is so obvious, simply removing a '%s' from a printf() statement, it spending time on trying to induce an uncommon error worth it? Can't you simply review the patch and say yes this bug is fixed?
do code review and verify the patch apply is sane: ... Patch003: nfs-utils-1.2.3-rpcsvcgssd-segfault.patch # 698220 - rpc.svcgssd: Segmentation fault on error %patch003 -p1 %changelog * Wed Apr 20 2011 Steve Dickson <steved> 1.2.3-7 - Fixed segfault in rpc.svcgssd (bz 698220) # ls -l SOURCES/nfs-utils-1.2.3-rpcsvcgssd-segfault.patch -rw-r--r--. 1 root root 939 Apr 20 13:17 SOURCES/nfs-utils-1.2.3-rpcsvcgssd-segfault.patch
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, an incorrect principal in the NFS client request could have caused the rpc.svcgssd daemon to terminate unexpectedly with a segmentation fault. This was caused by an error in the underlying code. This update adapts the code and rpc.svcgssd no longer crashes.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0738.html