gss_acquire_cred_impersonate_name & gss_init_sec_context does File Read (krb5.conf) on every request

Greg Hudson ghudson at mit.edu
Sun Jun 4 10:43:01 EDT 2017


On 06/03/2017 07:37 PM, Rahul G wrote:
> I noticed that the functions gss_acquire_cred_impersonate_name() &
> gss_init_sec_context() does a file read
> from krb5.conf (krb5.ini in windows) for reading realm information on every
> request.

The intent of the code is that krb5.conf should be read once, then
stat()'d on each request, and only re-read if it has changed.  There is
also once-per-second a limit on how often we call stat(), but that limit
is per profile object, and GSS calls create and destroy profile objects
on each call.

I don't have a workaround for you, but here are the relevant areas of code:

* From the GSS library, the profile object is created via a krb5_context
object through these functions:

  lib/gssapi/krb5/init_sec_context.c:krb5_gss_init_context()
  lib/krb5/krb/init_ctx.c:krb5_init_context()
  lib/krb5/krb/init_ctx.c:krb5_init_context_profile()
  lib/krb5/os/init_os_ctx.c:k5_os_init_context()
  lib/krb5/os/os_init_paths:os_init_paths()
  util/profile/prof_init.c:profile_init_flags()

* The code to reuse the memory copy of krb5.conf for different profile
objects is in util/profile/prof_file.c:profile_open_file().  It scans a
global table called g_shared_trees in the code (g_shared_trees is
#defined to krb5int_profile_shared_data.trees) for an entry with the
same filename.

* The code to stat and reread a file is in
util/profile/prof_file.c:profile_update_file_data_locked().

If you find that these mechanisms don't work as expected, please let us
know.  If there is a problem in the operation of profile_open_file()
with g_shared_trees, then I don't have a specific suggestion; however,
if there is a problem in the operation of
profile_update_file_data_locked(), it is easy (within the code) to
suppress that mechanism by adding "#undef HAVE_STAT" just before that
function.


More information about the kfwdev mailing list