[1963] in Kerberos_V5_Development
krb5.conf, kdc.conf, and --prefix
daemon@ATHENA.MIT.EDU (bjaspan@MIT.EDU)
Wed Nov 13 15:47:29 1996
From: bjaspan@MIT.EDU
Date: Wed, 13 Nov 1996 20:45:22 GMT
To: krb5-bugs@MIT.EDU, krbdev@MIT.EDU
Reply-To: bjaspan@MIT.EDU
>Submitter-Id: mit
>Originator: Barry Jaspan
>Organization:
mit
>Confidential: no
>Synopsis: krb5.conf, kdc.conf, and --prefix
>Severity: serious
>Priority: medium
>Category: krb5-misc
>Class: sw-bug
>Release: 1.0-development
>Environment:
System: IRIX beeblebrox 5.3 11091812 IP22 mips
>Description:
There is a combination of problems in krb5 involving krb5.conf,
kdc.conf, and the compile-time --prefix setting that needs to fixed.
Although it ought to be done by 1.0, I do not think it will be; I'm
submitting this PR to ensure it gets done soon thereafter. (If
someone thinks this should be done by 1.0, say so. I note that items
1 and 2 go together, but that item 3 is largely separate and perhaps
the most important.)
The first problem is that the structure of kdc.conf is confused. Some
items are specified in the [realms] section that are not realm
specific and therefore should be elsewhere. Many (perhaps all)
relations in this category are for the admin system and are therefore
my fault; I did not understand the nature of kdc.conf at the time
(which is part of why this PR is necessary).
The second problem is that the existence of kdc.conf is itself
confusing to users and inefficient in the code. The krb5.conf syntax
is sufficient to specify all of the kdc.conf information in krb5.conf.
Unless someone points out a good reason why the files need to be
separate, they should be merged. This will have the advantage of
eliminating the "alternative profile" kludge in (several redundant
places in) the code and simplifing the maintainance of KDCs.
The third problem is that the value of --prefix specified during
configure is built into numerous programs in the distribution, making
the results of "make install" absolute-path specific. It forces
admins to know where they are going to install the tree before they
run configure and build and, if they either change their mind or
didn't know they had to make the decision, they have to run a clean
build again from scratch (just re-running configure and make isn't
sufficient because programs with --prefix hard-coded are not
automatically rebuilt).
Here is my proposal:
o kdc.conf is merged into krb5.conf so that only one file exists.
o The path for krb5.conf is hard-coded into the libraries. The
default value is /etc/krb5.conf. It can be overridden by the
configure option --krb5confpath, after which a full rebuild is
necessary. The documentation *strongly* discourages the use of this
option. /etc/krb5.conf is The One True Path.
o There are several programs that need to know where to find krb5 data
files or binaries: KDC and kadmind need the database et al; kpropd
needs the path for kdb5_util; klogind, kshd, and telnetd need the path
for login.krb5 (I think that's all of them). In beta 7, the paths for
these files are determined at compile time by --prefix. Instead,
krb5.conf will now contain an install-prefix relation. Programs will
combine the install-prefix with a default suffix to locate the file;
for example, klogind will look for "<install-prefix>/sbin/login.krb5",
and the KDC/kadmind will look for "<install-prefix>/krb5kdc/principal"
as the database name; of course, the full value can also be completely
overriden for some of these values (ie: dbname, acl_file, admin_keytab
for the kdc/kadmind) if the program happens to allow that. Note that
since install-prefix is specified in krb5.conf, there is no
requirement for these paths to be the same on every machine in the
realm, which is good: clients should look in /usr/local, but the KDC
should probably look in /var/krb5 or somesuch.
o The default value for install-prefix can be anything, /usr/local is
fine, and the configure option --installprefix overrides it. Also,
please suggest a better name than "installprefix".
o make install by default installs into $(buildtop)/install/{bin,...}.
Since the distribution is now path-independent, this installation
directory can be copied to anywhere, and the sysadmin does not need to
recompile from scratch whenever he wants to change the location of the
binaries. The configure option --installpath overrides this value in
case the sysadmin knows for sure where he wants the files to go, but
again, this only affects the path name given to the install program.
Comments?
>How-To-Repeat:
>Fix:
