Misc ccache fixes

[nicowilliams]

[@riastradh here's a work-in-progress to fix some of the issues you turned up regarding KRB5CCNAME.]

083c994019e I'll mostly want to keep even if we switch to renaming the SQLite3 symbols.

This PR has a bunch of things:

• finally makes it possible to configure different defaults for all the otherwise-hard-coded default cache names
  • this is done via adding a [libdefaults] default_ccache_name_by_type parameter below which are per-cache type alternative default cache names
  • this makes it possible to -finally!- ensure that the tests do not write to the user's credentials caches
• completes previously half-baked support for non-default cache collections
  • adds krb5_cc_cache_match2() and krb5_cccol_cursor_new2() which take an optional collection name argument (<TYPE>:<name>)
  • enhances krb5_cc_new_unique() so that either its type or hint argument can be cache names and will be used to create the new [unique] cache in the named collection
  • extends krb5_cc_ops with several new methods to support all of this
  • repurposes the get_default_cache() method of krb5_cc_ops to have it return the token-expanded hard-coded default cache for that type, and adds a new get_primary_cache() method to return the current "switched" primary cache for a given collection (this is WIP not in this PR yet)
  • changes uses of krb5_cc_new_unique(), krb5_cc_cache_match in-tree to do use this new feature
• klist now knows that X-RMED-CONF: is the realm of cc config entries that have been removed and no longer shows those as >>>Expired<<<
• fixes FILE, DIR, and SCC bugs galore
  • klist -l output for DIR is nice now
• significantly enhances the SCC cache type
  • it is now indexed, which should support huge credentials caches better
  • it uses WAL mode
  • it cleans out expired non-cc-config entries sooner
  • uses FOREIGN KEYs
• documents credentials cache syntax, which is <TYPE>:[collection][:subsidiary] for all in-tree cache types except MEMORY (which is just MEMORY:<name> or MEMORY:anonymous) and FILE (which is FILE:[collection][+subsidiary])
  • as implied it is possible to use a bare cache type as a KRB5CCNAME value or -c option argument (e.g., FILE, DIR, ...) and the expected default will be used
  • ditto FILE:, DIR:, etc.
• improves tests/kdc/check-cc.in and lib/krb5/test_cc.c
• updates SQLite3 in-tree
• versions SQLite3 symbols in-tree (though we'll probably want to rename all the sqlite3 symbols anyways)

TODO:

• make check-valgrind should be clean now
• add kswitch ... [cmd [args]], and test that in tests/kdc/check-cc
• use or lose krb5_cc_parse_name()
• maybe fix Cache collections APIs and commands only support default collections #1146 now
  • the fix for Cache collections APIs and commands only support default collections #1146 is almost certainly incomplete -- we need a utility function that given a cache name that might be a bare type, a type and a collection name, or a full cache name, returns the TYPE:collection-name for that type, defaulting or not the collection name as appropriate
  • add tests of the fix to Cache collections APIs and commands only support default collections #1146
• add testing of krb5_cc_parse_name()
• add missing get_primay_name() methods to the in-tree cache types
• [ ] make all in-tree cache types use krb5_cc_parse_name() to DRY and get more consistent
• change all in-tree uses of krb5_cccol_cursor_new() to krb5_cccol_cursor_new2()

Anything else will go into a separate PR:

• fix collection cache iteration start method to take a collection name so that when iterating a non-default collection we don't end up iterating the default one instead
• rethink resolve_2() method and splitting of subsidiary cache names upstairs
• rethink escaping of filesystem-related characters in subsidiary names upstairs (rethinking done: we'll move this into the DIR and FILE cache types, thus allowing SCC, KCM, and API to have arbitrary subsidiary names w/o aliasing concerns)

[riastradh]

Thanks, I'll give it a whirl when I have a chance.

FYI (not sure where best to discuss this so just dropping it here), the main reason I was looking into this credential cache syntax -- other than to see whether the sqlite3 ccache was worth keeping or could be disabled to sidestep the symbol collision issues of https://gnats.NetBSD.org/57406 altogether -- was to see whether it would be reasonable to pick DIR or SCC as the default credential cache type instead of FILE so kinit could just work out of the box to log into multiple realms at the same time.

Right now I do KRB5_CONFIG=/home/riastradh/foo/krb5.conf KRB5CCNAME=/tmp/riastradh/krb5cc.foo kinit riastradh@FOO.COM and KRB5_CONFIG=/home/riastradh/bar/krb5.conf KRB5CCNAME=/tmp/riastradh/krb5cc.bar kinit riastradh@BAR.COM, but that's a mouthful to maintain for every kinit and every kerberized client, and I'd like it to work out of the box with none of that effoort.

So, before spending effort on tweaking the compile-time defaults, I thought I'd test the usability of DIR and SCC caches, with whatever is the default location for them, by setting KRB5CCNAME=DIR: or KRB5CCNAME=SCC:. Which, as you now know, didn't work out very well!

[riastradh]

I skimmed through the changes, haven't processed anything yet -- but I think the most important thing here is to have extensive automatic tests for all the kinds of settings that one might find in the environment and/or krb5.conf.

For the tests that are already in here, one appears to be failing:

FAIL: test_cc
=============

test_cc: krb5_cc_gen_new: MEMORY: Refusing to create a new unique cache in the default collection for cache type MEMORY because it is not the type of the default cache
FAIL test_cc (exit status: 1)

[nicowilliams]

Thanks, I'll give it a whirl when I have a chance.

Oh, it's not ready...

FYI (not sure where best to discuss this so just dropping it here), the main reason I was looking into this credential cache syntax -- other than to see whether the sqlite3 ccache was worth keeping or could be disabled to sidestep the symbol collision issues of https://gnats.netbsd.org/57406 altogether -- was to see whether it would be reasonable to pick DIR or SCC as the default credential cache type instead of FILE so kinit could just work out of the box to log into multiple realms at the same time.

Ah, well, in Heimdal the FILE cache type supports collections!

Try kinit --default-for-principal "$principal" then klist -l with the FILE ccache and with enable_file_cache_iteration = yes in [libdefaults], you'll see!

The context here is that the whole ccache collection concept that was grafted onto the krb5 API has been... somewhat unfinished this whole time, and this work is part of finishing it. Among the things that needed to be done to finish it was to teach the FILE cache type to be a collection cache type, and also to add a convention for naming sub-caches after the principals whose credentials they are intended to hold.

[nicowilliams]

[...] but I think the most important thing here is to have extensive automatic tests for all the kinds of settings that one might find in the environment and/or krb5.conf.

I've not gotten to that yet. I don't have a lot of time or energy right now to write extensive tests, but the two tests we have of ccaches have a good enough framework for adding more.

[riastradh]

Ah, well, in Heimdal the FILE cache type supports collections!

Try kinit --default-for-principal "$principal" then klist -l with the FILE ccache and with enable_file_cache_iteration = yes in [libdefaults], you'll see!

I see. My hope is that in NetBSD 11 (or maybe even 10) a user can just write kinit me@FOO.COM and kinit me@BAR.COM and run klist and it will all be there, and any kerberized/GSSAPI application like Firefox will seamlessly work for either realm, with no fiddling of knobs or extra arguments. How difficult do you imagine is the path to that future?

For now, I tried the configuration and command-line option, and this is what happened:

$ cat /tmp/krb5.conf
[libdefaults]
	enable_file_cache_iteration = yes
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/kinit --default-for-principal riastradh@A.EXAMPLE.COM
riastradh@A.EXAMPLE.COM's Password:
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/kinit --default-for-principal riastradh@B.EXAMPLE.COM
riastradh@B.EXAMPLE.COM's Password:
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist
klist: No ticket file: /tmp/krb5cc_1000
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist -l
   Name     Cache name     Expires
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist -A
$ 

If I set KRB5CCTYPE=DIR it seems to work a little better, although plain klist gives no indication that there may be multiple principals available and there's still weird expired krb5_ccache_conf_data tickets I mentioned in #1109:

$ KRB5_CONFIG=/tmp/krb5.conf KRB5CCTYPE=DIR prefix/bin/kinit --default-for-principal riastradh@A.EXAMPLE.COM
riastradh@A.EXAMPLE.COM's Password: 
$ KRB5_CONFIG=/tmp/krb5.conf KRB5CCTYPE=DIR prefix/bin/kinit --default-for-principal riastradh@B.EXAMPLE.COM
riastradh@B.EXAMPLE.COM's Password: 
$ KRB5_CONFIG=/tmp/krb5.conf KRB5CCTYPE=DIR prefix/bin/klist
Credentials cache: DIR::/tmp/krb5cc_1000_dir/tkt.riastradh@A.EXAMPLE.COM
        Principal: riastradh@A.EXAMPLE.COM

  Issued                Expires               Principal
May 29 23:11:09 2023  May 30 23:11:09 2023  krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM
May 29 23:11:09 2023  >>>Expired<<<         krb5_ccache_conf_data/start_realm@X-RMED-CONF:
$ KRB5_CONFIG=/tmp/krb5.conf KRB5CCTYPE=DIR prefix/bin/klist -l
   Name                            Cache name                                                    Expires
 riastradh@A.EXAMPLE.COM         FILE:/tmp/krb5cc_1000_dir/tkt.riastradh@A.EXAMPLE.COM         May 30 23:11:09 2023
 riastradh@B.EXAMPLE.COM         FILE:/tmp/krb5cc_1000_dir/tkt.riastradh@B.EXAMPLE.COM         May 30 23:11:22 2023
$ KRB5_CONFIG=/tmp/krb5.conf KRB5CCTYPE=DIR prefix/bin/klist -A
Credentials cache: FILE:/tmp/krb5cc_1000_dir/tkt.riastradh@A.EXAMPLE.COM
        Principal: riastradh@A.EXAMPLE.COM

  Issued                Expires               Principal
May 29 23:11:09 2023  May 30 23:11:09 2023  krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM
May 29 23:11:09 2023  >>>Expired<<<         krb5_ccache_conf_data/start_realm@X-RMED-CONF:
Credentials cache: FILE:/tmp/krb5cc_1000_dir/tkt.riastradh@B.EXAMPLE.COM
        Principal: riastradh@B.EXAMPLE.COM

  Issued                Expires               Principal
May 29 23:11:22 2023  May 30 23:11:22 2023  krbtgt/B.EXAMPLE.COM@B.EXAMPLE.COM
May 29 23:11:22 2023  >>>Expired<<<         krb5_ccache_conf_data/start_realm@X-RMED-CONF:

I suspect that KRB5CCTYPE=DIR will have advantages over KRB5CCTYPE=FILE, by narrowing any iteration to a single directory that the user owns.

[riastradh]

[...] but I think the most important thing here is to have extensive automatic tests for all the kinds of settings that one might find in the environment and/or krb5.conf.

I've not gotten to that yet. I don't have a lot of time or energy right now to write extensive tests, but the two tests we have of ccaches have a good enough framework for adding more.

Understood, didn't mean to direct your time! If I find time perhaps I can contribute to that.

[nicowilliams]

I see. My hope is that in NetBSD 11 (or maybe even 10) a user can just write kinit me@FOO.COM and kinit me@BAR.COM and run klist and it will all be there, [...]

That's there now even for FILE! But you do have to klist -l. I'm not sure how much we can change the default klist output... You know how it goes: people script around these tools even though they shouldn't because we didn't give them good porcelain to begin with (there's now decent JSON output support in klist).

[...] and any kerberized/GSSAPI application like Firefox will seamlessly work for either realm, with no fiddling of knobs or extra arguments. How difficult do you imagine is the path to that future?

Ah, well, that is a bit of another story. This is known as the "credential selection problem". If one knows the target service's realm a priori (either because it was furnished by the application or because we have a local [domain_realm] mapping for it) and that realm matches one of the client principals', then it's obvious what to do: use the matching credential. For all other cases it's much less obvious what to do.

Suppose you have no relevant [domain_realm] entries and that you have credentials for

• joeuser@A
• joeuser/admin@A
• joeuser@B
• joeuser@C

and you want to authenticate to host@somehost, now what?

Well, we could try all the credentials in... some order. How do we make that order deterministic? And what if you don't want to use admin credentials to authenticate to that service?

Keep in mind that the modern approach to determining a service's realm is to chase referrals from the client's "start realm" (i.e., the realm for which the client has a root krbtgt, where "root krbtgt" means that it's for and issued by the same realm). So we get to avoid an insecure DNS lookup for the host's realm, but then we also don't get to find the service's realm before trying to use a client credential, which means we have to try [a subset of] all the credentials we have in some canonical or configured order.

So it's complicated. The best we could do besides trying them all in C collation order is to have preferences recorded somewhere. MIT and Heimdal have been punting on this for decades, though MIT has done more work in this space than Heimdal.

It's not just Kerberos that has this problem -- PKI, JWT, you name it, they all have this problem.

And we also have a desire to support the most minimal local configuration possible -- zeroconf even. There's too many conflicts and too much mind reading to do here.

[nicowilliams]

Understood, didn't mean to direct your time! If I find time perhaps I can contribute to that.

Help would be appreciated, and we really appreciate your contributions so far! If I'm devoting some energy to this right now it's because a) I happen to need to add some functionality to Heimdal for $WORK, b) that coincides in time with your contributions, c) I don't want to discourage you.

[nicowilliams]

Ugh. There's several problems with the SCC cache type. For example, when we resolve a cache we recall it's rowid in the caches table, but then maybe we'll destroy or re-initialize it, and then that rowid will no longer be valid but we use it in the process of initializing which... is therefore racy and unsafe.

[nicowilliams]

This is still a work in progress. This now includes a significant set of [untested!] fixes to the SCC cache type:

• stop using row IDs -- that was causing race conditions
• use SQL to create random() (SQL function, not C) "new unique" caches, and use RETURNING
• stop using sqlite3_changes() and sqlite3_last_insert_rowid() now that we can use RETURNING
• add a server column to the credentials table so we can optimize scc_remove_cred() and implement a fast scc_retrieve()
• use FOREIGN KEYs to avoid the need for triggers and to simplify ccache detroy/initialize functions

In the process I'm upgrading SQLite3 in-tree to 3.42.0.

TODO:

• add an index on credentials (service)! (DONE)
• finish the rototill of scc_remove_cred() (needs testing)
• implement an scc_retrieve()! (now that we have a server name in the credentials table...) (needs testing)
• make lib/krb5/test_cc pass
• make tests/kdc/check-cc pass
• change configure.ac so that use of the in-tree SQLite3 is now mandatory
• maybe rename all the SQLite3 symbols in lib/sqlite to avoid conflicts
• fix up lib/sqlite/version-script.map to account for the upgrade of SQLite3
• add error checking of sqlite3_bind_text() calls
• audit the code for more bugs and design problems

[nicowilliams]

@riastradh it might be really nice to have a set of simple rules one could express for credential selection, rules of the form [service], hostname_fqdn_suffix, preferred_client_realm, preferred_number_of_client_principal_components, then one could write rules for the above joeuser example as follows:

• {"*", ".c.test.h5l.se", "B", 1}
• {"*", ".b.test.h5l.se", "C", 1}
• {"kadmin", "primary-kdc.test.h5l.se", "A", "2"}
• {"", "A", 1}

I think something like that could have value, at least as a starting point. I decidedly do not have the energy or mandate to work on this.

[riastradh]

I see. My hope is that in NetBSD 11 (or maybe even 10) a user can just write kinit me@FOO.COM and kinit me@BAR.COM and run klist and it will all be there, [...]

That's there now even for FILE! But you do have to klist -l.

Are you sure?

$ cat /tmp/krb5.conf
[libdefaults]
	enable_file_cache_iteration = yes
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/kinit riastradh@A.EXAMPLE.COM
riastradh@A.EXAMPLE.COM's Password:
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist
Credentials cache: FILE:/tmp/krb5cc_1000
        Principal: riastradh@A.EXAMPLE.COM

  Issued                Expires               Principal
May 30 16:46:32 2023  May 31 16:46:32 2023  krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist -l
   Name     Cache name     Expires
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist -A
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/kinit riastradh@B.EXAMPLE.COM
riastradh@B.EXAMPLE.COM's Password:
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist
Credentials cache: FILE:/tmp/krb5cc_1000
        Principal: riastradh@B.EXAMPLE.COM

  Issued                Expires               Principal
May 30 16:46:59 2023  May 31 16:46:59 2023  krbtgt/B.EXAMPLE.COM@B.EXAMPLE.COM
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist -l
   Name     Cache name     Expires
$ KRB5_CONFIG=/tmp/krb5.conf prefix/bin/klist -A
$ 

I'm not sure how much we can change the default klist output... You know how it goes: people script around these tools even though they shouldn't because we didn't give them good porcelain to begin with (there's now decent JSON output support in klist).

Fair enough. I'll settle for working klist -l or klist -A or whatever it is! (awk-friendly output would be nice too, if I could have a pony!)

[...] and any kerberized/GSSAPI application like Firefox will seamlessly work for either realm, with no fiddling of knobs or extra arguments. How difficult do you imagine is the path to that future?

Ah, well, that is a bit of another story. This is known as the "credential selection problem". If one knows the target service's realm a priori (either because it was furnished by the application or because we have a local [domain_realm] mapping for it) and that realm matches one of the client principals', then it's obvious what to do: use the matching credential. For all other cases it's much less obvious what to do.

Suppose you have no relevant [domain_realm] entries and that you have credentials for

• joeuser@A

• joeuser/admin@A

• joeuser@B

• joeuser@C

and you want to authenticate to host@somehost, now what?

Well, we could try all the credentials in... some order. How do we make that order deterministic? And what if you don't want to use admin credentials to authenticate to that service?

My expectation, from blind intuition without consulting any code or standards or documentation or past heated debates from mid-1990s mailing list archives:

1. Find somehost's realm -- either by domain-to-realm mapping in local configuration, or by DNS domain-to-realm mapping (unless it's disabled in the config). If no realm, fail.
2. If there's exactly one principal in that realm with an unexpired ticket, use that.
3. If there's more than one principal in that realm, whatever was most recently kinited and has yet to expire or something.

In case (3), I'm not sure the fine details of automagic default selection matter so much as providing a way for the user to specify a principal as the default for that realm, like kswitch jruser/admin@EXAMPLE.COM -- just like you have to type su or sudo for local privileged operations.

I'm sure I've missed lots of issues in more complex scenarios like cross-realm setups, but presumably whatever more complex rules handle these more complex scenarios could reduce, in the simpler scenario I sketched, to easy predictable rules like the ones above.

Of course, there's also a good chance that I missed some problems that are obvious to people who have been steeped in Kerberos development for ages, but I hope that if so, there's a good reason for such problems to get in the way of relatively simple scenarios, rather than simply that the rules above don't give a unique solution for more complex scenarios.

(I'm somewhat deliberately being naive/obtuse here because my goal is to make easy things work predictably, rather than setting all the knobs and options to do exactly what I want each time like I used to do for many years, so I'm trying to do the obvious thing and then seeing what actually falls apart when I try it. If nothing else, I hope this results in having any difficulties with the obvious thing get documented!)

Keep in mind that the modern approach to determining a service's realm is to chase referrals from the client's "start realm" (i.e., the realm for which the client has a root krbtgt, where "root krbtgt" means that it's for and issued by the same realm). So we get to avoid an insecure DNS lookup for the host's realm, but then we also don't get to find the service's realm before trying to use a client credential, which means we have to try [a subset of] all the credentials we have in some canonical or configured order.

What's the harm of a DNS lookup here? I see three possible negative outcomes from it:

1. Forgery leading to denial of service. Adversary convinces client to try a service ticket that somehost won't actually accept. But an adversary could have denied service by returning NXDOMAIN for the A record too, so I don't think this is worse.
2. Forgery leading to confusion. Adversary convinces client to try a service ticket that somehost accepts, so client is legitimately authenticated, but as a principal other than what they expected. It is possible to imagine contrived scenarios where this is a problem, but you could get into the same problem by, e.g., browsing just before and just after expiry of your tickets for one principal. I'm having a hard time imagining where this could get you into trouble that you weren't asking for by having all the tickets around in the first place.
3. Privacy leaks. Not actually sure offhand whether anything could leak here other than the fact that the user has a ticket, but let's suppose something does leak. In general I think preventing this requires disabling the use of DNS altogether, just like Tor-based browsers do, and I think for privacy it is reasonable to require setting an appropriate domain-to-realm mapping in the local configuration for the sites you do want to leak anything to (i.e., authenticate to).

And we also have a desire to support the most minimal local configuration possible -- zeroconf even. There's too many conflicts and too much mind reading to do here.

I certainly appreciate the desire for minimal or zero configuration, and that's what I'm aiming for too -- perhaps to ship an empty /etc/krb5.conf in NetBSD, or to safely obviate the need for having an /etc/krb5.conf at all. But I also expect that for certain purposes -- privacy of user's identity when browsing to non-kerberized sites, privacy of user's location when browsing to kerberized sites approved by the user -- some local configuration is needed. And I expect that for users juggling multiple identities within a realm, some extra interaction like kswitch jruser/admin@EXAMPLE.COM is reasonable.

Random thought: /etc/krb5.conf could start with a line saying what version it's based on and take all reasonable defaults from that version. New installations with /etc/krb5.conf created afresh with the new version line would get reasonable secure defaults without forcing users and admins to find all the obscure knobs to twiddle the right way; upgraded installations from old versions that lack a version line or still refer to an old version line wouldn't be impacted, but could be secured by updating the version line.

[nicowilliams]

Are you sure?

Ugh, it used to work, and I'll be fixing it.

[nicowilliams]

diff --git a/lib/krb5/fcache.c b/lib/krb5/fcache.c
index d94b0f48460..e147a4adfb7 100644
--- a/lib/krb5/fcache.c
+++ b/lib/krb5/fcache.c
@@ -1377,7 +1377,7 @@ fcc_get_cache_first(krb5_context context, krb5_cc_cursor *cursor)
         goto out;
     }

-    if (is_def_coll) {
+    if (is_def_coll && def_locs) {
         /* Since def_ccname is in the `def_locs', we'll include those */
         iter->locations = def_locs;
         free(iter->def_ccname);

fixes it, though I'll do better in a bit.

[nicowilliams]

My expectation, from blind intuition without consulting any code or standards or documentation or past heated debates from mid-1990s mailing list archives:

1. Find somehost's realm -- either by domain-to-realm mapping in local configuration, or by DNS domain-to-realm mapping (unless it's disabled in the config).  If no realm, fail.

The new hotness is to chase referrals and never bother doing DNS domain-to-realm mapping. This means relying on KDCs' [domain_realm] rules and not on DNS. It's a good thing, except that you lose the ability to make client credential selection decisions based on the host's realm.

In principle you can disable referrals chasing by using [libdefaults] name_canon_rules with the no_referrals option, but looking at the code I think that must be broken because it merely causes the client to not set the canonicalize flag on the TGS-REQ instead of going through the get_cred_kdc_capath() code path... Another thing to fix. Still, I much prefer using referrals to not using referrals.

2. If there's exactly one principal in that realm with an unexpired ticket, use that.

3. If there's _more than one_ principal in that realm, whatever was most recently kinited and has yet to expire or something.

The "one with non-expired tickets" thing makes for surprises.

In case (3), I'm not sure the fine details of automagic default selection matter so much as providing a way for the user to specify a principal as the default for that realm, like kswitch jruser/admin@EXAMPLE.COM -- just like you have to type su or sudo for local privileged operations.

kswitch is terrible because it's so global.

The point of creating a convention for naming caches in a collection after the client principal whose credentials they contain is to make it possible to just type KRB5CCNAME=...:${USER}@${OTHER_REALM} ..., or to cut-n-paste from klist -l output and have it be obvious when you look at the comment which cache that is -- compare to the new_unique convention that yields randomized ccache names!

[nicowilliams]

FILE and SCC as a collection should be working again in this PR, though I'm only testing by hand right now.

Next up: fix DIR, which too is broken.

[nicowilliams]

OK, DIR should be working to in this PR now, but still I've only done manual testing.

[nicowilliams]

lib/krb5/test_cc now passes.

[nicowilliams]

Using krb5_cc_parse_name() does simplify FILE a wee bit, and... maybe I can simplify DIR, we'll see.

[nicowilliams]

Using krb5_cc_parse_name() in the cache resolve methods really does not simplify things enough to be worthwhile. Especially not DIR, not as long as we support DIR::path/tktNAME syntax, and since MIT does, we must too.

[riastradh]

What can be done to unwedge this branch? Some other changes are blocked on this, like #1167. I forgot what the issues were holding this one up (other than circular tuit shortage).

[nicowilliams]

@riastradh er, well, I guess I need a code review.