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. _______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
