[krbdev.mit.edu #8042] kadmind w/interactive master key + full resync = dump failure

Benjamin Kaduk via RT rt-comment at krbdev.mit.edu
Tue Nov 25 15:14:57 EST 2014


[shawn.emery at oracle.com - Sat Nov 22 00:15:00 2014]:

> 
> When the master key is provided during kadmind startup and a full
> resync
> is required for a slave, kdb5_util incorrectly assumes that the stash
> file or that the password command argument is required to dump the
> database for propagation, resulting in error:
> 
> The problem is that kdb5_util makes a false assumption that the dump
> is not
> valid if the master key is not available.  This is a false assumption
> in a
> couple of aspects:
> 
> 1. The master key may not be readily available during automated
> propagation
> if the stash file has not been created.  Admins may not want stash
> files due
> to security risks.
> 
> 2. Having a master key does not necessarily mean that you can validate
> a db
> dump.  There is no way to validate the principals' keys even if they
> could be
> decrypted.  The only keys you could verify is the master key.
> 
> Suggested fix is to not make the absence of a stash file or a password
> command argument non-fatal:

I think that given how the dispatch table works, we can probably just add another column 
indicating whether the given subcommand requires the master key and pass that in to 
open_db_and_mkey(), so we can still require the master key for those operations which need it.

Tom notes that this might be a little exciting for the dump/load functionality that converts 
master keys.

I can probably look into a patch along that route.

-Ben


More information about the krb5-bugs mailing list