Hide Forgot
Description of problem: using ksu to become root fails (prompts for password) if my credential cache is the default DIR::/run/user/1000/krb5cc/tktvUFxkk form, but works if I choose a FILE:/tmp/somefile credential cache. Version-Release number of selected component (if applicable): krb5-workstation-1.11.3-10.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. get a kerberos TGT via pam or kinit 2. type "ksu" 3. Actual results: prompts for password if valid tgt is in a DIR:: credential cache. Works if I have a FILE:... credential cache. Expected results: should become root. Additional info:
We're currently tracking this in upstream RT. If I built a scratch package with the currently proposed (but not yet reviewed) patches, would you be able to give it a try?
Yes, I could test it.
Great! I did a preliminary merge and built this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6136204 If you can shake loose any bugs you find by testing with various types of KRB5CCNAME values and, because the patch set also attempts to get ksu to heed it, the default_ccache_name setting in krb5.conf, it'd be appreciated. The whole thing still needs to pass muster upstream, of course, but hopefully what's here isn't that far off the mark as far as what they'd like to end up merging.
I tested the new rpms, and it appears that ksu does work with both DIR: style as well as FILE: style ccaches. Did not see problems with other commands in krb5-workstation, although did not thoroughly test everything.
Thanks!
(In reply to Nalin Dahyabhai from comment #5) > Thanks! Any progress on this?
Due to issues with DIR cache we actually switched to using Kernel keyring for that matter. I am not sure this bug will ever be fixed. Nalin do you agree? Does ksu support Kernel keyring in the latest version?
The patches for keyrings cover both cases, since the breakage comes from assuming that the invoking user's ccache is always file (i.e., ignoring the type altogether and just assuming that we want to create a file to hold creds during the life of the process that we spawn). So far things look stable in internal testing, so I'll add them to Raw Hide and see if I can put together a testing update for F19 and F20.
I don't want to reset the clock on the currently-being-tested updates, so I'll hold off on adding these to testing updates for a bit. In the meantime, please see if builds from https://koji.fedoraproject.org/koji/buildinfo?buildID=495279 (for F19) and https://koji.fedoraproject.org/koji/buildinfo?buildID=495363 (for F20) work as expected. Thanks!
krb5-1.11.5-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/krb5-1.11.5-2.fc20
Package krb5-1.11.5-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing krb5-1.11.5-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2194/krb5-1.11.5-2.fc20 then log in and leave karma (feedback).
Seems to be fixed in latest testing versions for both f19 and f20 for me.
krb5-1.11.5-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.