Master key migration and the stash command

[Greg Hudson]

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
add_mkey -s.

* "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".

Sam wrote:
> 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."

Done.

> 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.