Keytab-based initiator creds design

[Nico Williams]

On Thu, Jun 7, 2012 at 1:56 PM, Simo Sorce <simo at redhat.com> wrote:
> In Fedora we are already moving the ccache to a standard place in /run,
> and it is non persistent as that filesystem is a tmpfs.
>
> So I think I like this proposal, it aligns well with what we are already
> trying to do there.

I know.  I had your use case and ones I had in my Solaris days in mind.

> The /run location should be /run/user/$USER/krb5/ccache though as that
> is where the various pam modules put stuff

Ideally this could be ./configured, no?

> For the permanent location (for keytab and
> default_principal) /var/lib/krb5/user/$USER or similar would probably be
> ok.

Actually, /var/spool/krb5/... no?

> Should we allow symlinks in the permanent location ?

Sure, why not.  If some daemon must use the same keytab as
/etc/krb5.keytab, why make the admin have to maintain a copy?  But if
there's an issue with gss proxy daemon...  -- is that what you're
concerned about?

> What about default principal ?

I'd say put it in a separate file.  But if it's not there then use the
princ of the first keytab entry.

> I am not 100% convinced we really want ephemeral locations for keytab
> and default_principal, or permanent locations for the ccache, but I
> wouldn't protest if they were implemented.

Just 'cause it's there doesn't mean you have to use it.

>> There should be an env var specifying alternative locations.  The
>> search order should be:
>>
>>  - env var, if present, always wins
>>  - ephemeral location
>>  - persistent location
>>  - traditional default ccache location (/tmp/krb5cc_<uid>) (this needs to
>>    be possible to disable in krb5.conf)
>
> I think we want to patch the traditional location out, at least in
> Fedora we will probably do so anyway due to tmp name spaces, so I am not
> too concerned about it.

Sure.

> Also why do you want them to be disabled ? A user can always go back to
> them by setting KRBCCNAME so what's the point ?

To not encourage its use.

>> 2) When gss_acquire_cred() is called with desired_name !=
>> GSS_C_NO_NAME then acquire a TGT if necessary for the given desired
>> name, or, if desired_name == GSS_C_NO_NAME, then acquire a TGT for the
>> default principal.  A default principal is: the default principal of
>> the user's ccache, if it exists, or the one found in the
>> default_principal file, or the principal of the first keytab entry in
>> the per-user keytab.
>>
>> In fact, some of this logic could be buried deep in libkrb5
>> (krb5_get_cred*()) rather than in the mechanism.
>>
>> 3) When gss_init_sec_context() is called with then call
>> gss_acquire_cred with desired_name == GSS_C_NO_NAME, try to determine
>> the correct client principal name to use for the given target name,
>> then acquire a credential handle for that name, else acquire a
>> credential handle for GSS_C_NO_NAME.
>>
>> 4) Always write the credential acquired with a keytab to a ccache if
>> possible, but use a memory ccache if there are errors writing to the
>> file/dir/ccapi ccache.
>
> Why would we want to use a mem cache in this case ? Wouldn't it be
> better to error off ?

I could go either way.

Nico
--