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):
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.

--- Additional comment from nalin 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 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 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 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 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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping