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>
* h-github/master: (64 commits)
refix socket wrappers with rk_
Patch from Secure Endpoints/Asanka Herath for windows support
unset KRB5CCNAME
its really just LIBADD more most of them
correct quoting
Use -lpthread for modern freebsd instead
clean KRB5CCNAME and KRB5_CONFIG, require test to reset them
more up ${env_setup}
use PTHREADS_LIBADD for freebsd6 and newer
add PTHREAD_LIBADD
add PTHREAD_LIBADD
add PTHREAD_LIBADD
switch to PTHREADS_LIBADD
log what the error string say too
More debug logging
sprinkle more 'echo "test failed"'
sprinkle 'echo "test failed"'
use calloc(), indent more prettier
in sh, equal compare is really = for strings, not ==
Check for duplicates, already loaded mechs
...
Conflicts (resolved):
lib/krb5/auth_context.c
lib/krb5/changepw.c
lib/krb5/context.c
lib/krb5/error_string.c
lib/krb5/kuserok.c
lib/krb5/libkrb5-exports.def.in
lib/krb5/net_write.c
lib/krb5/store_fd.c
lib/krb5/test_cc.c
lib/roken/strerror_r.c
