Fedora ticket cache location

[Nico Williams]

On Thu, Jun 7, 2012 at 4:02 PM, Russ Allbery <rra at stanford.edu> wrote:
> Nico Williams <nico at cryptonector.com> writes:
>> On Thu, Jun 7, 2012 at 3:50 PM, Russ Allbery <rra at stanford.edu> wrote:
>
>>> I think the only long-term viable way to handle credentials for file
>>> system access is to create some sort of explicit association between
>>> the current process or thread and the desired credentials in the
>>> kernel, since
>
>> And if the process fork()s?  Or if the thread creates a new thread?
>
> You need to express what semantics you want.  I think the AFS semantics of
> following fork and clone unless you explicitly say otherwise are probably
> the best default, but there will need to be some way to override it.

When is inheritance NOT desirable?  And how to specify what should
happen on fork/thread create?  Refuse to fork?  Or use some other
session for the new process/thread?  I think this is too complicated;
make these always inheritable and you're done.

>> This requires, IMO, that the new association be inheritable.  That's
>> what makes up a session though: the set of processes sharing the same
>> session characteristics through inheritance or explicit session joining.
>> Session keyrings, on Linux, for example, fulfill this.
>
> Yes.  Sessions are a fine way of handling this.

Right.

>> The OS has to solve this, indeed.  But Kerberos has to use the
>> corresponding facility.
>
> I'm not sure I agree, but maybe I don't understand what you mean.  I agree
> that processes are going to want to create a new session, but I don't
> think they would be asking the Kerberos library to do that.  Oh, maybe
> your argument is that it should be possible to ask the Kerberos library to
> create a new cache bound to the current session, as a high-level API?

I mean that the Kebreros libraries need to know how to find the
most-specific ccache/keytab/whatever, not that they need to know how
to create new sessions (indeed, that they must not do at all).

>>> Right now, (a) is the most common case, but indeed I think (b) is
>>> becoming more common.  Note that k5start and krenew already have code
>>> to create a new AFS session and tie it to the newly created
>>> credentials.
>
>> For (a) you need nothing special: just create a temp ccache and use it
>> via the APIs only.  (b) requires help from the OS.
>
> Except (a) brings us full-circle back to my question that started this
> thread: how do I get the Kerberos library to tell me *where* to create
> that temporary ticket cache so that it will be put in the desired location
> (and use the desired cache method, such as keyrings instead of files)?
>
> Ah... hm.  I think I see what you mean.  You're basically arguing that (a)
> is already satisified by krb5_cc_new_unique, and actually krenew needs

:)

> (b) because it's really setting up a new session and expects to be able to
> share that cache with its subprocesses?

:)

Yes, you read properly into what I was saying :)

Nico
--