Default client keytab name
dalmeida at MIT.EDU
Sat Jul 21 22:22:31 EDT 2012
Some further refinement on my thinking:
The acceptor keytab at /etc/krb5.keytab is locked down to root, right? So
perhaps we should have uid 0's client keytab at /etc/krb5.client.keytab.
If so, then option (2) could be the mirror of that for a root acceptor
keytab. Then option 1 could be used for all uids != 0. In theory, an
acceptor keytab could be stored there as well. The file part of the name
could be <uid>.keytab for acceptor and <uid>.client.keytab for initiator.
This would make it so when you copy the keytabs, they would not stomp over
each other if they end up in the same directory.
So my preference is for option 1 and option 2, where option 1 applies to uid
!= 0 and option 2 applies to uid = 0. Thoughts?
Is the file format for client (initiator) vs acceptor keytabs fundamentally
different? Is that why the .clkeytab extension is used? If so, I'm back on
board with .clkeytab (instead of .client.keytab). In fact, I think that I
am warming up to .clkeytab regardless.
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
Sent: Saturday, July 21, 2012 6:20 PM
To: ghudson at mit.edu
Cc: krbdev at mit.edu
Subject: Re: Default client keytab name
On Sat, Jul 21, 2012 at 9:29 AM, <ghudson at mit.edu> wrote:
> Soon there will be support for parameterizing the name. Once that's
> in, what should we use for the built-in default? Here are some
I vote for 1. First, some of us already do this, using $KRB5_KTNAME,
so this would just be convenient. Second, we're talking about
variable state, even if it changes rarely, not configuration, so I
think this belongs in /var.
Perhaps one could argue that secrets are rarely stored in /var and
that storing secrets there necessitates updating backup strategies.
But this would be true any time a new file with secrets is added even
The fact that the path in (1) is likely to get adjusted by vendors
doesn't bother me. I would like to see krb5-config(1) have an option
to print the configured default path, and if it can be set in
configuration, then it should also have an option to print the one
currently in effect. This will help portable applications like wallet
and krb5_admin, and it will help sysadmins' scripting.
> A relevant question is whether a system-wide default initiator keytab
> ever makes sense. A system-wide acceptor keytab makes sense when all
> of the accepting daemons (which may be just sshd) are running as root.
The whole point of parametrizing this path is precisely that it makes
no sense to have a system-wide initiator keytab default :)
krbdev mailing list krbdev at mit.edu
More information about the krbdev