Profile include support

[Russ Allbery]

ghudson at MIT.EDU writes:

> * glob() may not exist on all systems. Does it exist on Windows? If it
>   does not exist, what fallback position should the code take? Options
>   are:
>   - Fail to compile if glob() does not exist.
>   - Disable include support if glob() does not exist.
>   - Allow only includes of explicit filenames if glob() does not
>     exist.
>   - Provide a glob() implementation if it does not exist. This may be
>     a substantial amount of code.

For the record, most software that I'm familiar with implements only
include <file> and include <directory>, where the latter includes every
file in the directory except for those meeting some exclusion criteria
(common ones being no files starting with a period or containing a period,
tilde, or hash, which takes care of things like .rpmsave and editor backup
files).  While some software supports including a glob of files, I've
never seen much need for it and people seem happy when I only provide file
names and directories as long as it's well-documented.

> * The syntax "include PATTERN" is simple and clear, but may not be
>   optimal. It could break existing profile files which contain an
>   "initial comment" (any text before the first line beginning with
>   '[') with a line which happens to begin with "include".

I don't think this is a big worry.  I've been using Kerberos for years and
didn't know that was possible, and I suspect that's the case for most
people.  Someone has to both know that this is possible and use that
feature and get unlucky enough to have the line start with that word.

>   Also, adding an include directive anywhere other than the beginning of
>   a krb5.conf file would cause earlier versions of krb5 to generate a
>   syntax error. Other syntax options include:
>   - Masquerade as a comment: #include PATTERN
>   - Masquerade as a section: [include PATTERN]
>   - Distinctive punctuation: @include PATTERN

I think include PATTERN is fine, and [include PATTERN] is the next best
choice.  I think #include PATTERN is more likely to misinterpret existing
files than include PATTERN.

> * 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?

It is extremely useful for testing to support including relative paths.
All my software that supports inclusion of configuration files supports
relative paths, and I've never had trouble with this.

> * Should an include directive ever result in a fatal error? Possible
>   error cases include:
>   - Including an explicit filename (not a pattern) which does not
>     exist.

This could probably usefully be an error.

>   - Including a pattern which has no matches. Note that it is
>     impossible to distinguish this case from the previous one without
>     breaking the abstraction barrier of glob().

This should definitely not be an error if you're going to stay with that
implementation strategy, but I think you should change to support
including of a directory, in which case you can just consider including an
empty directory to not be an error.

>   - Including a pattern or filename which attempts to descend into
>     directories which the process has no permission to read.

This should also be an error or at least be reported somewhere.  We
recently ran into a bug that took us a full day to track down to krb5.conf
not being world-readable; at no point did we get useful error messages out
of the version of Kerberos being used (whatever came with RHEL 4, I
believe).  We shouldn't introduce more problems of this type.

>   - Including a pattern or filename which matches a file, but the file
>     cannot be opened.

I think this should also be an error.

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

That's sufficiently bad that I think you should consider finding some way
to fix that as part of this work.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>