Bug 698220

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