krb5 context initialization dilema

[Zhanna Tsitkov]

Hi,
During krb5 library context initialization an attempt to retrieve some  
values from libdefaults section of the configuration file is made. It  
appears that only in three  out of ten cases we verify if the reading  
of the values from the configuration file was successful. The  
attributes that we check the profile_get return code are:
allow_weak_crypto,
ignore_acceptor_hostname,
plugin_base_dir,

We ignore any errors coming from the misconfiguration of the following  
attributes:

clockskew,
kdc_req_checksum_type,
ap_req_checksum_type,
safe_checksum_type,
kdc_timesync,
kdc_default_options,
ccache_type.

Encryption types are not read during init_context time.

We have few options here how to deal with this issue.

The first option is to leave the  code alone, but to report the  
configuration errors (if any) via trace logging mechanism.  It is good  
for the administrators who are OK with the loose, somewhat inaccurate   
configuration, as soon as nothing seemed to be broken - at least at  
the first glance.  Eventually, they may want to turn on the trace  
logging, check the errors reported during library context  
initialization and fix them.  The problem here is that it might be too  
late...

The second option is to report the configuration error as a context  
initialization error, and  via trace logging.  We  already fail   
context creation if the problem is encountered for three attributes -  
allow_weak_crypto, ignore_acceptor_hostname and plugin_base_dir.  So  
failing for the other seven would not only add a consistency to the  
context initialization code, but would make it cleaner.  This approach  
would appeal to the administrators who strongly believe in the power  
of configuration ;)  , when configuration must not be ignored.  It  
would also allow earlier error detection if misconfiguration happens.

Finally, the third option is do not attempt to retrieve these seven  
"unverified" values during context initialization and read/cache them  
on-demand, when they are needed.

Please, share your preferences regarding this issue.

Thanks,
Zhanna


Zhanna Tsitkov
tsitkova at mit.edu