[1930] in Kerberos_V5_Development
Configuration directories
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Nov 10 19:33:27 1996
Date: Sun, 10 Nov 1996 19:33:18 -0500 (EST)
From: Greg Hudson <ghudson@MIT.EDU>
To: source-developers@MIT.EDU
Cc: krbdev@MIT.EDU
I'd like to solicit people's opinions on the question of where Athena
packages should look for their configuration files.
Possible answers are:
1. Always look for configuration files in /etc. This is
consistent with what operating systems do, and it's what
the Linux file hierarchy standard says to do.
2. Always look for configuration files in @sysconfdir@ (which
defaults to ${prefix}/etc, although we would probably
override it in config.site to be /etc/athena). This is
what the FSF would like people to do when you use Autoconf.
3. Look for configuration files in /etc, and if you don't find
them there, look in @sysconfdir@. This is what my recent
release of Hesiod does, but it's not a big deal to change
that.
4. Look for configuration files in /etc and in @sysconfdir@;
if both are present, merge them together with the file in
/etc taking precedence. This is what Kerberos 5 release
1.0 will do.
Here are the arguments four and against each of the four approaches:
1. All configuration files for all software running on the
system will be found in the same place. Moreover, no
matter how the package is configured, it will always
find a configuration file placed in /etc. This avoids
problems like we've had with Kerberos 4, where some
versions would look in /etc, some in /etc/kerberosIV, and
some in /etc/athena for their configuration files.
A disadvantage is that you can't put configuration files
in a central area; however, most big distributed
environments (including ours) need to have control over
/etc on the client machines anyway.
2. This gives the package configurer the flexibility to
decide where to put configuration files, and it lets you
put configuration files in a distributed location if you
want. It has the nasty wart that if your package is
integrated into an operating system, @sysconfdir@ needs to
be overriden to be /etc or configuration files will wind up
in the highly non-traditional /usr/etc.
3. You can all the advantages of (1) and (2), but the
corresponding disadvantage that someone might find a
configuration file in @sysconfdir@, edit it, and discover
that their changes have no effect because the actual
configuration file was in /etc.
There are some other disadvantages: it complicates your
code a bit, and it's aesthetically displeasing to look for
a file in several places. Things also get a little fuzzy
when you look at directories full of configuration files,
such as Zephyr ACL files.
4. You get the advantages of (3) with some of the
disadvantages gone, but someone might still try to make a
change to the configuration file in @sysconfdir@ and find
that the change is overridden in the file in /etc.
This approach complicates your code a lot, and assumes that
merging two configuration files makes sense for your
configuration language.
An orthogonal question is:
Should we consider it a requirement that packages accept an
environment variable telling them where to look for
configuration data? If so, should there be a standard form
for the name and value of this environment variable, and what
should it be?
Such environment variables can introduce security holes in setuid
programs or daemons that run as root, so I'm not sure if we should
adopt this as a requirement. (Arguably, though, privileged programs
in vulnerable situations, such as login and ksu, should be stripping
their environment during the time they have privileges.)
On the other hand, it adds a fair amount of flexibility, especially
for doing regression tests.
