[PATCHSET] Introduce SDB - a KDC backend abstraction

[Andrew Bartlett]

On Fri, 2015-07-31 at 12:06 +0200, Andreas Schneider wrote:
> On Friday 31 July 2015 10:47:32 Andrew Bartlett wrote:
> > On Wed, 2015-07-29 at 13:36 +0200, Andreas Schneider wrote:
> > > Hello,
> > > 
> > > attached is a patchset which brings us again a step forward. It
> > > introduces SDB
> > > a KDC backend abstraction. It implements a sdb to hdb translation
> > > layer.
> > > 
> > > I've gone through the patches with Alexander and we cleaned up the
> > > interface
> > > yesterday. It passes a full 'make test' on my machine.
> > > 
> > > I will plan to push it tomorrow.
> > 
> > I'm sorry to see this pushed in such a rush.  As I've said before, this
> > is a delicate area, and I would like to explicitly review each change
> > here, and to other parts of our KDC infrastructure.
> 
> I do not see a rush here. 

It was the "I will plan to push it tomorrow." part that frustrated me in
that respect.  Given that too many details and assumptions about how the
current Heimdal integration works are not expressed in writing in the
way that they should, I would like to keep a very close eye on this to
ensure it is the success we need it to be. 

> We introduced SDB last year at the SambaXP 
> conference and we explained the implementation at the SambaXP conference again 
> this year. SDB is in place since quite some time now.
> 
> We based SDB on HDB so that the changes to the code are minimal.

It is very nice design in that respect.  I was expecting something more
intrusive. 

> > It seems we now have a partial copy of the Heimdal ABI in our tree,
> > that if we diverge will cause some nasty challenges.
> 
> Which changes to HDB are expected that you see nasty challenges coming up?

I'm just worried that when we have a #define that needs to be the same
as the Heimdal define, but isn't linked to that define by the compiler,
that this kind of thing becomes mind-bending to debug.  I don't expect
such changes, but I would like some protections, like in the Heimdal
case importing the header and using the original values, or failing to
build with a #error if they don't match. 

> > I still don't see
> > why couldn't we just keep the hdb structures, but if we must have this
> > half-copy, can we please have some assertions that the #defines and
> > bitmaps in sdb.h really are identical?
> 
> Because we build against system MIT Kerberos and do not want to build and/or 
> link Heimdal!

Certainly.  What I meant was in the Heimdal case, as that build is what
needs the protection. 

> If the flags are changed, we can change sdb_flags_to_hdb_flags() to translate 
> them instead of just copying them ...
> 
> > In particular, why was int2SDBFlags done in the sdb layer, rather than
> > in the hdb layer?
> 
> It is used by db-glue?

OK.  It just seemed the ideal way to keep Samba's SDB from needing to
use a matching bit-field. 

As I said at SambaXP, despite my long history in the Heimdal effort, it
is clear to me that the future is in using MIT Kerberos.  

Since then, discussion on heimdal-discuss has shown that the Heimdal
team is not in a position to commit to make published releases in a
timely fashion.  While we have managed to get the majority of our
lorikeet-heimdal patches merged upstream, it took ages and I've had to
use my own commit rights to get Metze's more recent changes merged. 

What remains is to get Samba from here to when the MIT Krb5 effort
finishes in the safest way possible.  For my part, I'll try and keep a
closer eye on the WIP branches (please mail me when you have something
interesting to look at) and if you can let me give a final look-over
before they land, that would be great.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba