-----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@xxxxxxxxxx> > 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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
