[7713] in Kerberos

home help back first fref pref prev next nref lref last post

Possible removal of DB support in krb5_aname_to_localname

daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Aug 2 22:09:29 1996

Date: Fri, 2 Aug 1996 22:00:51 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: kerberos@MIT.EDU

-----BEGIN PGP SIGNED MESSAGE-----




	The current version of Mit Kerberos (Kerberos V5 Beta 6)
includes a feature in a library routine called krb5_aname_to_localname
that allows a database (dbm or db format) to be used to map principals
to local user names.  You use this functionality if you have lines in
krb5.conf that look like:

auth_to_local = DB:<name>

	Unfortunately, this complicates the libkrb5.a library because
it makes it depend on a database library.  For example, we currently
don't have an acceptable solution to build shared libraries on Linux
with the new version of the Berkeley Db library that we are using for
future releases of Kerberos.  

	I am proposing to remove the functionality of having an aname
database as of the next Kerberos beta.  This proposal has not met
within any strong objections within the development community, so I am
seeing if there are any comments from users about this possibility.

	Note that other mechanisms for handling translation of
principals to local names will still exist:

* Explicit mappings can be expressed in krb5.conf.  This is just as
flexible as the db functionality for small data sets, although the
linear search and requirement that krb5.conf change would get annoying
if many principals were handled this way.

* The rule mechanism allows mechanical rewriting of principals into
usernames, including regexp substitutions on many platforms.

* The default rule for handling the local realm still exists.  For
example, user@LOCAL_REALM is mapped to user.

	If you have any comments about the removal of this
functionality, please let us know soon so that we can make a decision
before the release.

- --Sam



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQEVAwUBMgKyokJYVPVo3rXRAQH+fgf9G3cjjffeByeM3ntLyaWeN3nafVYzIAMD
6WCkKS/9T4G0ukgoizAMw5MkkxBhE5VfPbrZQCjrbUNDk2mkjKLB1IkUfFAztnGt
CP1Xm9eNZXSf2fSN94S7f5cTZl723t52L7OOwgeBoHQm/gSDCmrmKCoPSr2O/1Dq
f9FvJ1J7HkimhH1auAePHbaMWtkhnMxELqq6+DJzz2a7WYg1m4pmz22w5gly7drJ
XLjDEqK32DQmAufv2BXD8Ga3J+WAzKh8+MKb/GSGkQALjOQnlzFCrHVaK6Pm6/LY
Asa9WbB2un6kTQj5rnF6KBO6MZO9CiXmNuAW16vlYPOsD+lzkloFwg==
=VKJG
-----END PGP SIGNATURE-----

home help back first fref pref prev next nref lref last post