[1381] in Kerberos_V5_Development
keytab editing
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Fri Jul 12 22:55:32 1996
To: krbdev@MIT.EDU
Date: Fri, 12 Jul 1996 22:55:11 EDT
From: Marc Horowitz <marc@cygnus.com>
There's an interesting problem with the keytab editor. If no keytab
is specified on the command line, then the default keytab will be
used. However, the default keytab is FILE:/dir/foo. This is
readonly, rendering the editor mostly useless.
I can think of a number of solutions to this problem:
- require that a keytab be specified. This makes the program a
little less convenient to use.
- if the keytab name is FILE:*, mangle it to WRFILE:*. This doesn't
scale, since as new FOO/WRFOO pairs are added, the keytab program will
need to know about them.
- remove the FILE/WRFILE distinction. Have resolve/default try to
open the keytab read-write, and if that fails, read-only. (This is
actually the current state of affairs, since the keytab isn't actually
opened until an operation is performed, and only the privileges
requested (rdonly or rdwr) are requested. WRFILE:/dir/foo isn't
necessarily ever opened for write.) This means that an application
which writes to keytabs will need to do a fake write if it wants to
know if the keytab is writeable, which is gross. (This is also the
current state, and is a bug in itself, as the kdc can get out of sync
with the keytab this way.)
- make WRFILE available to all applications, and make the default
WRFILE. This has problems similar to the above two possibilities if
the keytab is readable, but not writeable, to the application.
- remove the FILE/WRFILE distinction, and add a call to query if the
keytab is writeable. This could be done in a parallel fashion to
krb5_cc_set_flags(). If the writeable flag is requested, but open for
write fails, then the application could exit before the kdc is
changed.
- remove the FILE/WRFILE distinction, and add new krb5_kt_default_foo
and krb5_kt_resolve_foo calls which take an open mode. This open-mode
is tested at resolve-time, so if the writing is requested, but not
available, the failure can be reported early, before the kdc is
changed.
I think one of the last two changes is best. I think the last is a
little more clean, but the penultimate is more like other stuff in the
api.
Marc
