Bug 488815

Summary: audit rpc.gssd and rpc.svcgssd for memory leaks and other problems
Product: [Fedora] Fedora Reporter: Jeff Layton <jlayton>
Component: nfs-utilsAssignee: Jeff Layton <jlayton>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: chuck.lever, dwalsh, eparis, nalin, steved
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-14 08:13:57 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
output from gssd running inside valgrind none

Description Jeff Layton 2009-03-05 15:08:38 EST
In preparation for doing the conversion of rpc.gssd and rpc.svcgssd to IPv6, we need to convert them to use tirpc. This seems to basically work, but I need to check that we're not introducing new bugs and memory leaks.

Use valgrind to test these daemons and see if there are existing bugs that need to be fixed before we make these changes
Comment 1 Jeff Layton 2009-03-05 15:10:41 EST
Created attachment 334203 [details]
output from gssd running inside valgrind

Output from gssd running inside valgrind...

The test just did 100 mounts and unmounts of an export with -o sec=krb5
Comment 2 Jeff Layton 2009-03-05 15:51:27 EST
Not too bad...

No unreachable memory after the run. Most of the reachable memory is related to selinux, but it's not clear to me why krb5 is linked to libselinux in the first place, but I have an open inquiry into our selinux folks to track that down.

Next I'll look at the warnings that popped before the program exited...
Comment 3 Daniel Walsh 2009-03-05 16:01:03 EST
libkerberos is using libselinux to figure out how to label files it creates like servtabs and credential caches.

It calls matchpathcon which will load the entire file context file and compile the regexs to match the location of the file.
Comment 4 Eric Paris 2009-03-05 16:42:15 EST
doesn't matchpathcon provide a mechanism to only load the part of the regex DB that we need?  I think we could probably see some time and space savings if we move actively pare things down.

Like restorecon loads the whole db, but if I called restorecon -R /home I only need to load the /home labels.....
Comment 5 Daniel Walsh 2009-03-06 08:43:06 EST
Well Nalin did the work, so I am adding him to the list.   Yes I think you can pare it down, but since the library never knows exactly where the file is going to be created, it can not pare it down.  restorecon is an app so it makes it easier.
Comment 6 Eric Paris 2009-03-06 08:55:40 EST
Restorecon doesn't do it either (but I was saying that's another example of where we should be using that functionality)
Comment 7 Daniel Walsh 2009-03-06 09:04:09 EST
udev does, but it knows that it will only be asked for labels under /dev

restorecon -R /usr /lib /var

Makes it difficult to judge whether this is work it.
Comment 8 Jeff Layton 2009-03-06 09:23:03 EST
This may be a silly suggestion from a security standpoint, but why not put this table in something that can be shared between processes. i.e. have a privileged daemon load the table and then have others mmap it with read-only privs.
Comment 9 Daniel Walsh 2009-03-06 10:05:46 EST
Potentially could be done as a service.  One problem though is relabeling/labeling needs to be done very early in the boot process, udev/earch /etc/rc.sysnet.  So having this service running would be a problem.  Also this has not proven to be that big of a problem in the past.
Comment 10 Bug Zapper 2009-06-09 07:55:53 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 11 Jeff Layton 2009-10-14 08:13:57 EDT
Ok, closing this one out since I've cleaned up all of the memory leaks in gssd and svcgssd that I could find. The selinux table is another matter however. We might want to consider cloning this bug to address the libselinux memory utilization at some point, but I'll leave that up to the SELinux folks...