On Tue, 2005-07-19 at 14:09 +0200, Love Hörnquist Åstrand wrote:
> Andrew Bartlett <abartlet@samba.org> writes:
>
> > I've been chatting with lha on IRC about HDB, but I wanted to bring
> > these things to the list, for a more concrete discussion:
> >
> > I've been thinking about how I would like (in my ideal world) the HDB
> > layer do develop, in support of Samba4's use of Heimdal.
> >
> > The particular feature I'm after in extending HDB is a private pointer,
> > based on an encapsulation of the existing asn.1 hdb_entry:
> >
> > struct hdb_container {
> > hdb_entry *entry;
> > void *private;
> > }
> >
> > I would then add a new hdb_free_entry() method, to free hdb_container
> > (and the backend-specific private).
>
> So what I like about the current interface (just talking about the
> interface, not content), is that each entry is free-standing from the
> backend, no reference counting, no locking, no thread issues.
>
> One idea I have is splitting the KDC into a crypto part and a protocol part
> to protect the long term keys in case of a compromise, and adding stuff
> like hdb_access_chec, hdb_get_pac, and hdb_verify_pac [1] might complicate
> the model.
>
> When thinking about it, it might not be that bad, and really, the KDC
> should't really need to write into the HDB layer (never call ->hdb_store) ,
> so there isn't much need for transaction safefy ? And to provide you with
> hooks to the real entry, just create a one entry cache in the hdb backend
> should do it.
Are you implying that we should have a static variable in the backend
for this, or something different. I really want to avoid that if
possible, particularly when there is perfectly adequate context variable
(the entry) that can be extended.
> [1] Shouldn't these last two be hdb_{add,verify}_authorization_data ?
Probably :-)
--
Andrew Bartlett http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc. http://suse.de
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
This is a digitally signed message part