Bug 846472 - Slow performance when using Kerberos
Slow performance when using Kerberos
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5 (Show other bugs)
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
Zbysek MRAZ
Depends On:
  Show dependency treegraph
Reported: 2012-08-07 17:12 EDT by Steve Huff
Modified: 2013-07-03 09:16 EDT (History)
9 users (show)

See Also:
Fixed In Version: krb5-1.9-34.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 751736
Last Closed: 2013-02-21 03:37:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Huff 2012-08-07 17:12:37 EDT
I am seeing the same problem on RHEL6, and so am cloning this bug to save it from the fc15 EOL process.

+++ This bug was initially created as a clone of Bug #751736 +++

Description of problem:

Version-Release number of selected component (if applicable):

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.

--- Additional comment from nalin@redhat.com on 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?

--- Additional comment from dwalsh@redhat.com on 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.

--- Additional comment from nalin@redhat.com on 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.

--- Additional comment from dwalsh@redhat.com on 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.

--- Additional comment from endoflife@fedoraproject.org on 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:
Comment 2 Karel Srot 2012-08-17 03:30:28 EDT
was this bug resolved in upstream? I can see that the Fedora bug was closed when reaching F15 end-of-life.
Comment 3 Daniel Walsh 2012-08-17 06:15:44 EDT
We are working on a couple of different solutions to speed up the loading of the file_context regex files, in Rawhide, if we get a good solution we will probably back port to rhel6
Comment 4 Nalin Dahyabhai 2012-08-20 12:07:51 EDT
(In reply to comment #2)
> Hi,
> was this bug resolved in upstream? I can see that the Fedora bug was closed
> when reaching F15 end-of-life.

Upstream doesn't currently include any of the labeling changes, which is probably a good thing since we're still making changes to how it works.  The changes I have in mind landed in two parts: the first in krb5-1.10.2-1.fc18 (later pulled in to an update to F17), the second in krb5-1.10.2-7.fc18.
Comment 12 errata-xmlrpc 2013-02-21 03:37:25 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.