bug in profile_update_file_data_locked()?

[Greg Hudson]

On 09/10/2012 05:57 PM, Will Fiveash wrote:
> If I comment out  
>     if (now == data->last_stat && data->root != NULL) {
> 
> and always execute the following:
> 
>     if (stat(data->filespec, &st)) {
> 
> then I don't see KADM5_MISSING_KRB5_CONF_PARAMS being returned.
> 
> Thoughts?

The intent of the code you found is that profile changes on disk will be
noticed within one second, but that we won't do a stat() call on the
same profile more than once per second.  Even if we removed that
optimization, we wouldn't necessarily notice two changes which happen
within the same second.

I've thought about changing to a simpler scheme like Heimdal's where the
profile always read for a new krb5_context but is never re-read during
the lifetime of that context.  This wouldn't change a lot of
user-visible behavior since many profile values are explicitly cached in
a krb5 context or a realm_params structure anyway.

For this to be reasonably efficient, we'd want to reduce the number of
krb5 contexts created by the GSSAPI code.  Heimdal handles this by
having a per-thread krb5 context.  The last time I discussed that idea,
Sam had some objections to the idea that a GSSAPI object might behave
differently if used in different threads.  (He suggested that objects
like GSS sec contexts would remember the context used when they were
created, but that's not safe without locks; the remembered per-thread
context context could wind up being used at the same time as another
call in the original thread.)