[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on LDAP support in heimdal
- To: Lars Kellogg-Stedman <lars@oddbit.com>
- Subject: Re: Comments on LDAP support in heimdal
- From: Love Hörnquist Åstrand <lha@kth.se>
- Date: Tue, 01 Nov 2005 10:31:26 +0100
- Cc: heimdal-discuss@sics.se
- In-Reply-To: <c27faacf0510301556m1ee0fe5ete517a537606499e7@mail.gmail.com> (LarsKellogg-Stedman's message of "Sun, 30 Oct 2005 18:56:12 -0500")
- References: <c27faacf0510301556m1ee0fe5ete517a537606499e7@mail.gmail.com>
- Sender: owner-heimdal-discuss@sics.se
- User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.0.50 (darwin)
Lars Kellogg-Stedman <lars@oddbit.com> writes:
> Howdy,
>
> While setting up Heimdal kerberos with the LDAP backend, I ran into a few
> stumbling blocks. Everything is working now, but I'm curious what other
> folks think about these issues:
>
> (1) Problems with LDAP hdb as a dynamic module.
>
> I originally built heimdal with --enable-hdb-openldap-module. I was using
> the following database configuration:
>
> [kdc]
> database = {
> realm = EXAMPLE.COM
> dbname = ldap:ou=dc=example,dc=com
> mkey_file = /var/heimdal/m-key
> }
>
> Running 'kadmin -l', and then 'init EXAMPLE.COM' simply created a *file*
> called "ldap:dc=example,dc=com" in the current working directory.
> It didn't look as if any attempt was made to load the LDAP hdb backend.
>
> Building without --enable-hdb-openldap-module fixed this problem. I've got
> two questions:
>
> (a) Is this (LDAP hdb as a loadable module) currently expected to work?
Yes, but as the code works now, it will only work where here are no db
support compiled in.
> (b) wouldn't it make more sense to treat a dbname of ldap:.. as an error
> if we can't load the appropriate hdb module?
Yes, it would, but there is backward compatiblity code in there to make it
work with older configurations. How about this patch ?
--- lib/hdb/hdb.c 19 Oct 2005 15:51:40 +0200 1.56
+++ lib/hdb/hdb.c 01 Nov 2005 10:25:05 +0100
@@ -55,11 +55,9 @@
{"ldap:", hdb_ldap_create},
#endif
#if HAVE_DB1 || HAVE_DB3
- {"", hdb_db_create},
+ {"/", hdb_db_create},
#elif defined(HAVE_NDBM)
- {"", hdb_ndbm_create},
-#elif defined(OPENLDAP) && !defined(OPENLDAP_MODULE)
- {"", hdb_ldap_create},
+ {"/", hdb_ndbm_create},
#endif
{NULL, NULL}
};
> (2) Problems with log_file.
>
> When using the LDAP backend, the logic that creates the name of the log
> file is arguably sub-optimal -- as in (1), it simply appends ".log" to
> dbname and creates the file in the current working directory. When using
> non-file backends, might it make more sense to create the log file under
> /var/heimdal? For example, given dbname=ldap:dc=example,dc=com, maybe
> default to /var/heimdal/_ldap_dc=example_dc=com -- that is, replace
> "special" characters with "_", and maybe add a leading "_" to indicate a
> generated filename. Or at the very least, exit with an error if
> log_file hasn't been given explicitly in the configuration.
Its true that the HDB_DB_DIR should probably be prefixed, and / replaced
with something else.
How about this for now ?
--- lib/kadm5/context_s.c 17 Jun 2005 07:13:26 +0200 1.18
+++ lib/kadm5/context_s.c 01 Nov 2005 10:30:35 +0100
@@ -76,9 +76,10 @@
else {
p = strrchr(dbname, '.');
if(p == NULL)
- asprintf(variable, "%s.%s", dbname, ext);
+ asprintf(variable, "%s/%s.%s", HDB_DB_DIR, dbname, ext);
else
- asprintf(variable, "%.*s.%s", (int)(p - dbname), dbname, ext);
+ asprintf(variable, "%s/%.*s.%s",
+ HDB_DB_DIR, (int)(p - dbname), dbname, ext);
}
}
Love
PGP signature