Default client keytab name

[Simo Sorce]

On Sat, 2012-07-21 at 10:29 -0400, ghudson at MIT.EDU wrote:
> For the keytab initiation project, we created a new concept called the
> default client keytab.  Currently, the hardcoded value (if there's no
> $KRB5_CLIENT_KTNAME or default_client_keytab_name profile setting) is
> /etc/krb5.client-keytab, which is just a placeholder.
> 
> 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
> options:
> 
>   1. Something like %{LOCALSTATEDIR}/krb5/%{uid}/clkeytab
> 
>      This gets parameterization support for the client keytab right
>      off the bat.  But it's not very memorable, and because it treads
>      on the most poorly standardized part of the Unix filesystem, it's
>      likely to be adjusted by each vendor.

I would like this one if it is configurable at build time.

>   2. Still a file in /etc.  (Perhaps /etc/krb5.clkeytab for brevity.)
> 
>      This has the advantage of being nicely parallel to the default
>      acceptor keytab.  You'll have to set default_client_keytab_name
>      in krb5.conf to in order to avoid configuring daemons with
>      environment variables (if they're running as different uids and
>      need separate keytabs, that is), but that's also true for the
>      default acceptor keytab.

Does it really make sense to have a common file name for all users, when
it is clear that most users will not have access to it ?

I feel that using a fixed name would be an error.

>   3. Nothing.  If you don't configure a name, there isn't one, and
>      krb5_kt_client_default() returns an error.
> 
>      This might make sense if we think (1) and (2) are bad choices.
> 
> What are people's opinions?  I'm leaning away from (1) myself, and
> would be fine with (2) or (3).

My preference order is (1) (3) (2) I think. but I do not feel strongly
about it.

> 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.

Right, daemons are few, clients are many more usually (think daemons
that want access to secure NFS and run as individual users. I think this
is why I do not like 2.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York