krb5_cc_gen_new

[Alexandra Ellwood]

I have no objections to the hint parameter so long as it is optional. 
I've been wanting a useful krb5_cc_*() API to create temporary ccaches 
for a while.

One thing that I would like to suggest is that the function take 
separate type and name arguments for the hint. The name argument would 
work as described earlier in the discussion or like mktemp or whatever. 
  The type argument would either specify what type of ccache the caller 
wanted, or be NULL, in which case the library would create a ccache of 
the default type (ie: whatever type the library feels like using).

Doing this makes parsing easier in the library.  It also makes it 
easier for callers who are trying to create a cache based on an 
existing ccache since krb5_cc_get_name() and krb5_cc_get_type() already 
return the split type and name strings.

The reason I want this is that the KLL frequently wants to create 
krb5_ccache references to temporary CCAPI ccaches because it needs to 
get tickets, make them available to plugins, and destroy them if a 
plugin fails without destroying any preexisting tickets in the 
destination ccache. These ccaches must be CCAPI ccaches because the KLL 
needs to be able to store v4 credentials in them. However, KLL never 
cares about the temporary name, which means that with the proposed API, 
I'd be passing "API:" as my hint string and then checking that I really 
got a CCAPI ccache.

I've always been a little frustrated that the krb5_cc_* APIs return 
separate name and type strings, but take unparsed strings (eg: 
"FILE:/tmp/tickets"). I usually end up parsing and unparsing strings 
all over the place. I realize this is convenient for command line 
utilities which get the unparsed string on the command line, but it's a 
pain for the KLL and GUI apps.


Note that making the name hint work with the CCAPI is going to be a 
pain in the butt. The CCAPI only provides a "create new unique ccache" 
API which does not take a hint for the name. So the implementation in 
the case where the name has been specified will have to try opening 
different potentially unique names until one errors out, or it will 
have to walk the entire ccache (potentially really slow). To avoid 
inefficiency, we'll probably have to add a new function to the CCAPI or 
assert that the name part of the hint is unsupported for the CCAPI 
(this is already true for other parts of the krb5_cc_* APIs where 
functionality doesn't make sense). CCAPI ccache names are rarely (if 
ever) exposed to the user because the default ccache is stored in the 
ccache collection (not an environment variable) and there's no file on 
disk.  --lxs
-----------------------------------------------------------------------
Alexandra Ellwood  lxs at mit.edu
MIT Information Services & Technology  http://mit.edu/lxs/www/
-----------------------------------------------------------------------