Bug 488815
| Summary: | audit rpc.gssd and rpc.svcgssd for memory leaks and other problems | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeff Layton <jlayton> | ||||
| Component: | nfs-utils | Assignee: | Jeff Layton <jlayton> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 11 | CC: | chuck.lever, dwalsh, eparis, nalin, steved | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-10-14 12:13:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Jeff Layton
2009-03-05 20:08:38 UTC
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
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... 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. 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..... 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. Restorecon doesn't do it either (but I was saying that's another example of where we should be using that functionality) 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. 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. 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. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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... |