[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