[1386] in Kerberos_V5_Development
Re: keytab editing
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Jul 15 12:08:33 1996
Date: Mon, 15 Jul 1996 12:08:12 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: Marc Horowitz <marc@cygnus.com>
Cc: krbdev@MIT.EDU
In-Reply-To: [1381]
There's an interesting problem with the keytab editor.
First note: kadm5_keytab is obsolete. I ported it, and it works,
but I also add exactly the same functionality to the kadmin cli with
the ktadd and ktremove commands. I don't see any reason that a
separate keytab editor should continue to exist. (Hmmm... well, I
guess there is one possibility: kadmin requires you to get tickets
before you do anything, including running ktremove, but
kadm5_keytab does not. <shrug>)
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.
kadmin (and kadm5_keytab, for that matter) set the default keytab to
WRFILE:/etc/v5srvtab. I assume you mean to say that if you specify
just a path name (/dir/foo) that it defaults to FILE:/dir/foo.
However, I notice in the unit-test's init_db script that it runs
kadm5_keytab with the argument /kadm5/ovsec_adm.srvtab, and that seems
to work. I don't exactly understand why, nor why it is behaving
differently for you.
I think the idea of adding a "writeable" flag that can be querired
with krb5_cc_get_flags is a good choice; I like it more than adding a
parallel set of of cc_open commands that take a mode.
I think the reason FILE and WRFILE exist is so that most apps can use
FILE and be sure they do not accidentally modify the keytab, even if
they have OS permission to do so. I don't think keytabs are so
critical that this is important, but we should explcitly decided that
before removing the distinction and leaving it up only to OS
permissions.
Another possible idea is to create a new virtual type, DEF (and WRDEF
if we keep that distinction) that specifies whether the keytab is
writeable but also specifies that the default type (currently FILE (or
WRFILE)) should be used. I'm not clear what this buys us, though.
Barry
