Fedora ticket cache location

[Russ Allbery]

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.

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

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

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

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>