Krb5 admin patches 2nd
This has all the patches needed for krb5_admind to build and pass most tests, that includes:
- more kadm5 API compatibility (including very basic profile functionality)
- multi-kvno support (useful for key rollovers) (a test for this is included in tests/db/check-kdc)
Unfinished:
- password history (currently uses key history, needs to be separated and use digests)
- policies (only default policy allowed)
- mit kdb changes not tested yet
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
The libkadm5 functions hdb_open() and close around all HDB ops. This
meant the previous implementation of kadm5_lock() and unlock would
always result in a core dump. Now we hdb_open() for write in
kadm5_lock() and hdb_close() in kadm5_unlock(), with all kadm5_s_*()
functions now not opening nor closing the HDB when the server context
keep_open flag is set.
Also, there's now kadmin(8) lock and unlock commands. These are there
primarily as a way to test the kadm5_lock()/unlock() operations, but
MIT's kadmin.local also has lock/unlock commands, and these can be
useful for scripting (though they require much care).
It turns out that updates of kvno but not key data and vice-versa are
both, allowed and actually done (e.g, in kadmin's ank). Doing the right
thing in these cases turns out to be a bit tricky, but this commit ought
to do it.
add_enctype() was not fetching the kvno of the principal it was
modifying, and it was not setting the kvno of the new keys (instead it
set it to 0). This worked fine before multi-kvno, but broke then. The
fix is to fetch the kvno and set the new keys' kvno to that.
I'm thinking of adding a new kadmin command to prune old kvnos by date
or kvno differential...
most of these warnings are not problems because of ample
use of abort() calls. However, the large number of warnings
makes it difficult to identify real problems. Initialize
the variables to shut up the compilers.
Change-Id: I8477c11b17c7b6a7d9074c721fdd2d7303b186a8
Pass the function name into foreach_principal instead of the static
"get" string, so the correct function is reported in errors in
kadmin list.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
kadmin list and kadmin get -t used the same output display logic
as short output, which meant that they called kadm5_get_principal
for each principal. However, they then just threw that output
away since the terse format displays only the principal name.
For terse get output, instead use a separate set of functions that
just print the string version of the principal name and do not
retrieve additional information.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
When the principal is retrieved from the database via libkadm5srv, the
keys are always decrypted, so the reported mkvno is always 0. Rather
than returning 0 and implying that the key in the database is not
encrypted, report the mkvno as unknown for right now.
A better fix is required to either not decrypt the keys when retrieving
get information or to get the mkvno before keys are decrypted.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
