Profile include support

[Ken Raeburn]

On Aug 23, 2010, at 11:03, ghudson at MIT.EDU wrote:
> * Nothing in the design prevents include directives containing
>  relative paths or patterns. Such an include directive would have
>  unpredictable effects since the current working directory would be
>  different for different invocations of the krb5 library. Should the
>  profile library protect the administrator by restricting include
>  directives to absolute paths? If so, how should it portably
>  recognize an absolute path?

Interpreting a relative path as relative to the working directory of the process seems like a bad idea, though I haven't thought much about the testing case Russ pointed out.

However, interpreting it as relative to the location of the config file seems reasonable.  So you could have a krb5.conf that says "include krb5.conf.d/*" and it would Just Work, pulling in config files from a subdirectory in the same place where the krb5.conf itself lives.

>  Note that because of the profile library architecture, it cannot
>  generate extended errors.

Russ is right, this should be fixed, whether as part of this project or separately.  But if krb5_init_context can fail because of a profile library error, it becomes difficult to pass the error back to the application, even with profile library API changes.  If we can go config-file-free (I forget, did that ever get fully implemented?), then certainly the krb5_context can hold the profile library error info.

Ken