Master key migration and the stash command
ghudson at MIT.EDU
Thu Jan 29 14:20:53 EST 2009
Due to time constraints, I'm going to have to punt the use case of
creating a stash file without an existing database. It's not rocket
science, but it requires adjusting the machinery of kdb5_util (right
now, if there's no database, "kdb5_util stash" fails out before
kdb5_stash() is even invoked) and we're branching in 22 hours. Sorry to
get anyone's hopes up.
Side issues I noticed during the implementation process:
* kdb5_util should call quit() during the normal exit path in order to
zap master key data.
* "kdb5_util add_mkey" with no stash file produces an assertion failure.
(It also doesn't prompt for an existing master key, which I think it
needs in order to operate.) Also, see below about the behavior of
* "kdb_util create" supposedly defaults to not creating a stash file.
However, this default does not always work. kdb5_create() creates the
stash file unconditionally, then removes it with unlink() if do_stash is
false. However, if you did not supply a stash filename on the command
line, it winds up calling unlink(NULL) which fails silently. This bug
precedes the mkey_migrate branch.
On Wed, 2009-01-28 at 15:50 -0600, Will Fiveash wrote:
> 1. Will it completely overwrite the existing stash, thus destroying any
> keys in the stash not found in the master princ? I'm okay with the
> answer being yes as the master princ better have all mkeys in use.
Yes. I don't think there's ever a need to manipulate the stash file
beyond "store all current master keys". If there is such a need,
there's always ktutil.
> BTW, when I look at the current code in krb5_def_store_mkey() I think
> that it is a shortcoming that the code does not preserve the existing
> stash keys in the new keytab (my bad). Sounds like your mods above will
> take care of this in a reasonable way (see item 1).
Yes; however, "kdb5_util add_mkey -s" will need to be adjusted. Right
now it overwrites the stash with the new key. From a practical
perspective that's okay in most scenarios, but for cleanliness of design
it should do the same thing as "kdb_util add_mkey; kdb5_util stash".
> 1) If the stash command does not prompt for a password, it explain
> why. I.E. print a message like "An existing stash file worked to
> open the database; updating the stash file wih all master keys."
> 2) If the stash command is run, there is an existing stash file, and
> the stash file cannot decrypt the master key, then the user be
> prompted for a password.
That fell out of the implementation naturally.
More information about the krbdev