Fedora ticket cache location
Nico Williams
nico at cryptonector.com
Thu Jun 7 17:07:12 EDT 2012
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
--
More information about the krbdev
mailing list