Profile include support
raeburn at MIT.EDU
Mon Aug 23 18:08:13 EDT 2010
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.
More information about the krbdev