Red Hat Bugzilla – Bug 985107
Please change the default location for Kerberos credential caches to DIR:/run/usr/UID/krb5cc
Last modified: 2014-02-06 13:32:25 EST
Description of problem: As part of the Fedora features https://fedoraproject.org/wiki/Features/KRB5CacheMove and https://fedoraproject.org/wiki/Features/KRB5DirCache, we'd like to have winbind's ccache management facility store a user's Kerberos credentials in the per-user /run/user/$UID directory. Specifically, either on F19 and later, or if you prefer, if the default name returned by krb5_cc_default_name() begins with "DIR:", instead of storing credentials in "FILE:/tmp/krb5cc_%d", we'd like to use "DIR:/run/user/%d/krb5cc" instead. There's a bit more work involved, since on subsequent saves you'll probably want to locate an extant ccache in the collection rather than create a new one, but hopefully that's manageable. Version-Release number of selected component (if applicable): samba-winbind-4.0.7-1.fc19 (based on conversation in bug #796429)
Günther and I implemented it last week in Samba. It can be configured by setting krb5_cc_type in pam_winbind.conf. We need a bug for authconfig to change it to DIR or DIR:/run/user/%u/krb5cc once we have the patch in Samba.
You can define the location by setting: krb5_ccache_type = DIR:/run/user/%u/krb5cc in /etc/security/pam_winbind.conf now.
samba-4.0.7-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/samba-4.0.7-3.fc19
Package samba-4.0.7-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing samba-4.0.7-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13541/samba-4.0.7-3.fc19 then log in and leave karma (feedback).
How is /run/user/${uid}/ supposed to be created? Testing this with 'su dwoodhou' from another user, I found /run/user/501/krb5cc owned by root.root. I removed the entire /run/user/501 directory, then tried 'su dwoodhou' again. And it didn't get recreated. I created it manually, and now the krb5cc directory is *slightly* saner. Now it's owned by the 'dwoodhou' user at least, and the 'root' group: [dwoodhou@i7 dwmw2]$ ls -la /run/user/501/krb5cc/ total 12 drwx------. 2 dwoodhou root 80 Jul 26 13:50 . drwxr-xr-x. 3 dwoodhou dwoodhou 60 Jul 26 13:50 .. -rw-------. 1 dwoodhou root 4 Jul 26 13:50 primary -rw-------. 1 dwoodhou root 5922 Jul 26 13:50 tkt
I have an odd setup here. My local username is 'dwmw2' not 'dwoodhou' for historical reasons. So I don't usually *use* the 'dwoodhou' local user for anything but this kind of test, and I actually use 'wbinfo -K dwoodhou' after logging in as dwmw2. That still puts the krb5cc in the old location though: [dwmw2@i7 ~]$ rm /tmp/krb5cc_500 [dwmw2@i7 ~]$ wbinfo -K dwoodhou Enter dwoodhou's password: plaintext kerberos password authentication for [dwoodhou] succeeded (requesting cctype: FILE) credentials were put in: FILE:/tmp/krb5cc_500 [dwmw2@i7 ~]$ klist klist: No credentials cache found (ticket cache DIR::/run/user/500/krb5cc/tkt) [dwmw2@i7 ~]$ ls -l /tmp/krb5cc_500 -rw-------. 1 dwmw2 root 5922 Jul 26 13:56 /tmp/krb5cc_500 [dwmw2@i7 ~]$ Using '--pam-login=dwoodhou' doesn't seem to create a creds cache *anywhere*, for *either* user. Although a real PAM login would.
And 'ssh dwoodhou@localhost' results in no ccache, and: kinit failed for 'dwoodhou@GER.CORP.INTEL.COM' with: No credentials cache found (-1765328189) ads_kdestroy: krb5_cc_resolve failed: No credentials cache found winbindd_raw_kerberos_login: could not destroy krb5 credential cache: No credentials cache found ads_kdestroy: krb5_cc_destroy failed: No credentials cache found falling back to samlogon [dwmw2@i7 ~]$ sudo rm -rf /run/user/501 [dwmw2@i7 ~]$ ssh dwoodhou@localhost dwoodhou@localhost's password: Last login: Fri Jul 26 14:04:05 2013 from localhost.localdomain [dwoodhou@i7 ~]$ ls -l /run/user/501 total 0 [dwoodhou@i7 ~]$
samba-4.0.8-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/samba-4.0.8-1.fc19
samba-4.0.8-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Is it not feasible for samba to read the location from krb5.conf like everything else does rather than having to configure the same thing in a different location? I guess that's an upstream issue though.
And I can confirm "wbinfo -K" does not use the: krb5_ccache_type = DIR:/run/user/%u/krb5cc that I added to /etc/security/pam_winbind.conf: $ wbinfo -K brian Enter brian's password: plaintext kerberos password authentication for [brian] succeeded (requesting cctype: FILE) credentials were put in: FILE:/tmp/krb5cc_1001 So can we reopen this ticket for this failure?
Samba uses multiple ccaches for different purposes. It is downstream-specific detail where they are placed since it is more of a distribution policy. So no need to handle it at upstream, we already have means to handle specific locations.
We have the means to handle the specific locations but ISTR the stumbling block was *creating* the /run/user/%u/ directory at the appropriate time. For that reason I have configured my users' systems to use the old-style FILE ccache in /tmp. Not quite sure what provoked Brian to revert that change, but it's a timely reminder for me to chase this up...
wbinfo has --krb5ccname option to pass the non-default ccache name. winbindd unserstands other types of ccaches (KEYRING: and DIR:) but since request comes over unix domain socket, it cannot assume the calling party knows about these other types and defaults to a safe FILE: default.
(In reply to Alexander Bokovoy from comment #16) > wbinfo has --krb5ccname option to pass the non-default ccache name. Ahhh. That's not documented in the manpage. In any case, that doesn't seem to be working here: $ wbinfo --krb5ccname DIR:/run/user/1001/krb5cc -K brian Enter brian's password: plaintext kerberos password authentication for [brian] succeeded (requesting cctype: DIR:/run/user/1001/krb5cc) It says it's writing it but it doesn't actually get written: $ ls -l /run/user/1001/krb5cc ls: cannot access /run/user/1001/krb5cc: No such file or directory (In reply to David Woodhouse from comment #15) > Not quite sure what provoked Brian to revert that > change Multiple realm support.
(In reply to Brian J. Murrell from comment #17) > (In reply to Alexander Bokovoy from comment #16) > > wbinfo has --krb5ccname option to pass the non-default ccache name. > > Ahhh. That's not documented in the manpage. In any case, that doesn't seem > to be working here: > > $ wbinfo --krb5ccname DIR:/run/user/1001/krb5cc -K brian > Enter brian's password: > plaintext kerberos password authentication for [brian] succeeded (requesting > cctype: DIR:/run/user/1001/krb5cc) > > It says it's writing it but it doesn't actually get written: > > $ ls -l /run/user/1001/krb5cc > ls: cannot access /run/user/1001/krb5cc: No such file or directory This is exactly what couldn't be fixed from Samba side because /run/user/%u/krb5cc is privileged and cannot be created by libkrb5. We had quite a discussion in F19 time with systemd folks on how to solve it (see fedora development mailing list archives) which resulted in creating KEYRING: ccache type. Unfortunately, KEYRING: is limited in how other processes can access it.