Fedora ticket cache location

[Russ Allbery]

Nico Williams <nico at cryptonector.com> writes:
> On Thu, Jun 7, 2012 at 3:17 PM, Russ Allbery <rra at stanford.edu> wrote:

>> I want to replace that hard-coded file location with something that
>> respects the system configuration for where such ticket caches should
>> be written.  I think I need an interface where I pass in the user or
>> the UID or the like and get back either a krb5_ccache or a cache
>> identifier that I should use for a temporary ticket cache.

> If you want to pass in a UID.. that's not portable (a username would be
> OK though).  And you'll probably also want to pass in a PID, PAG, ...
> All not portable.

I want a temporary ticket cache, so I'm not particularly interested in PID
or PAG for this particular purpose.  You're going to hand me back a new
unique cache and then I'll handle visibility from there.  Although I
realize I may need to give you a hint for keyring caches so that you can
set up appropriate permissions.

I think using usernames instead of UIDs is awful on UNIX, since usernames
are meaningless on UNIX for access control and much harder to come by for
a running process.  You've now dragged all of nsswitch into the picture,
including possible remote service queries and remote outages, for no real
purpose.  Insisting that programs know which string username they're
running as doesn't strike me as a good requirement, and it's not a natural
requirement for most UNIX software.

> I recommend an API and UI for listing the compiled-in and configured
> search orders, plus an API and UI for listing the effective
> ccache/keytab for the calling process.

That sounds remarkably annoying to use as an application developer.  I
think a good design goal here should be to make this not much harder to
use than hardcoding /tmp if you want people to actually use it.

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