Default libkrb5 ccache location

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/26/2013 11:31 AM, Miloslav Trmač wrote:
> On Fri, Jul 26, 2013 at 5:17 PM, Simo Sorce <simo at redhat.com>
> wrote:
>> On Fri, 2013-07-26 at 17:07 +0200, Tomas Mraz wrote:
>>>> For the record, I like this plan. It should also serve to
>>>> address a number of unfortunate edge-cases, particularly
>>>> those around the semi-sessions created by 'su' and 'sudo'.
>>> 
>>> I'd rather like to see a plan that would fix also other similar
>>> uses off /run/user/<uid> and not just the Kerberos.
>>> Unfortunately Lennart insists otherwise so I am afraid that
>>> this is doomed to fail and hacks like this one above will
>>> prevail.
>> 
>> 
>> While I'd like to have a solution for the world, I really want to
>> fix the kerberos issue now. We can transition later to a better
>> way to do this, but I do not think we can live with these bugs
>> for long while we wait for the perfect solution.
> 
> If the expectation is that the cache may be moving around again
> once or twice, should we be thinking about hiding/deemphasizing
> the location from users so that they aren't troubled by the moves?
> Or perhaps the exact opposite - make KRB5CCNAME prominent to give 
> everybody a working solution until we get something that works well
> in the default case (... while possibly limiting our flexibility
> for the future)?

Well, *users* should not really notice or care where these things are
unless they go looking for them. All a user cares about is whether
they can authenticate and have access to their SSO credentials after
doing so.

Moving this location around really impacts only packagers and certain
developers, which is a different audience (and one that's usually more
accepting of change, provided that the benefits are clearly
communicated). In this case, we've gone from "Ugly, works most of the
time but very fragile" (/tmp) to "When it works, it's nearly perfect,
but it is broken for some very important use-cases" (/run/user/UID)
and now we're trying for "Works for everyone without the fragility of
the original approach." (/run/kerberos/UID)

The middle step was necessary - I think - in order to get us to the
place we really wanted to be. I agree with Simo that it would be nice
to have a solution that could solve all problems for every subsystem,
but at the moment we really need to fix this one because it's causing
problems for a lot of people.

Also, there's no guarantee that a perfect solution for other
subsystems will ever actually show up. It may be that each
service/application will have its own needs that have to be met
separately. We can investigate this, but I don't think it should hold
up the short-term fix.

Also, Tomas, you stated: "I'd rather like to see a plan that would fix
also other similar uses off /run/user/<uid> and not just the
Kerberos.". Can you point us at some places that have similar issues?
I have no doubt they exist, but they're not on my radar right now and
I'd like to keep track of them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHyoksACgkQeiVVYja6o6MbHwCePYjymhU08eG2yK3cZNeXNlSp
S8cAnRujUKYMdJrU3e1uneasVJYPxN8X
=Scj7
-----END PGP SIGNATURE-----