Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Slow performance when using Kerberos|
|Product:||[Fedora] Fedora||Reporter:||Sylvain Baubeau <bob>|
|Component:||krb5||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||buzilla.redhat.com, dwalsh, nalin, shuff|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||846472 (view as bug list)||Environment:|
|Last Closed:||2012-08-07 13:27:50 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Sylvain Baubeau 2011-11-07 06:59:56 EST
Description of problem: Version-Release number of selected component (if applicable): 1.9.1 How reproducible: Any classic Kerberos conversation : I used a mod_auth_kerb and the test script of the 'python-krbV package. Steps to Reproduce: 1. time curl --negotiate -u user: http://localhost/url-protected-by-modauthkerb Actual results: It really depends on your PC but I get an about 100 ms response time. Expected results: A lot shorter time, lets say 10 ms ;) Additional info: The performance issue seems to be related to the krb5-1.9-selinux-label.patch that is applied on the package. Without this patch the performance are back to normal. This is a serious problem as the performance loss is quite severe specifically in a 'delegation' scenario where 100 ms are lost for every 'bounce' on a Kerberos protected service. In my setup the time a request is cut down from 300 ms to 20ms without the patch.
Comment 1 Nalin Dahyabhai 2011-11-07 12:11:18 EST
Currently we load the label configuration whenever we need to determine the label to give to a file that's about to be created, to ensure that it's labeled correctly. We might be able to cut down on the amount of time that a process spends doing this after it's loaded the file once, but loading the file the first time is still going to be expensive. Dan, is there a cleaner way to speed this up?
Comment 2 Daniel Walsh 2011-11-07 16:12:19 EST
Well if you are doing it every time, You could specify the prefix path. For example, udev knows that it will only be labeling /dev/... So it tells selinux that it will only be labeling /dev and then only loads the regular expressions that would effect a object in /dev. If we could know that the contents are only in /tmp or /etc/ you could use the prefix. In F15 you can only specify one Prefix, in F16 I believe you can specify multiple.
Comment 3 Nalin Dahyabhai 2011-11-07 16:38:58 EST
Hmm, at the point where we initialize the labeling handle, we actually know the target path exactly. Will passing it in as a value for a SELABEL_OPT_SUBSET option save us much time? If so, it'd make for a pretty trivial fix.
Comment 4 Daniel Walsh 2011-11-07 16:42:18 EST
Well then you take the hit every time. If it is a long running process you might want to load all regex, if you come up and execute a signal lookup and exit then using prefixes would be much faster. I think the prefix has to be a directory though.
Comment 5 Fedora End Of Life 2012-08-07 13:27:53 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping