Bug 985016 - Credential cache directory /run/user/0/krb5cc does not exist
Credential cache directory /run/user/0/krb5cc does not exist
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5 (Show other bugs)
7.0
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Nalin Dahyabhai
Patrik Kis
: TestBlocker
Depends On: 961235 961510 967509
Blocks: 949853 965419 977972
  Show dependency treegraph
 
Reported: 2013-07-16 10:54 EDT by Scott Poore
Modified: 2016-05-12 06:26 EDT (History)
18 users (show)

See Also:
Fixed In Version: krb5-1.11.3-16.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 961235
Environment:
Last Closed: 2014-06-13 06:00:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Scott Poore 2013-07-16 10:54:05 EDT
+++ This bug was initially created as a clone of Bug #961235 +++

I'm trying to 'kinit -k' as root, and I get this message about my credential cache directory not existing. 

[stef@stef ~]$ sudo kinit Administrator@BORG.THEWALTER.LAN
kinit: Credential cache directory /run/user/0/krb5cc does not exist while getting default ccache

Name        : krb5-workstation
Arch        : x86_64
Version     : 1.11.2
Release     : 4.fc19
Size        : 2.3 M

--- Additional comment from Patrik Kis on 2013-05-09 04:31:53 EDT ---

I hit this bug by doing kinit as non-root user:

$ kinit Bender@AD.BASEOS.QE
kinit: Credential cache directory /run/user/1000/krb5cc does not exist while getting default ccache

Root works:

# kinit Bender@AD.BASEOS.QE
Password for Bender@AD.BASEOS.QE: 
# klist 
Ticket cache: DIR::/run/user/0/krb5cc/tktxJkaGT
Default principal: Bender@AD.BASEOS.QE

Valid starting       Expires              Service principal
05/09/2013 10:30:40  05/09/2013 20:30:40  krbtgt/AD.BASEOS.QE@AD.BASEOS.QE
	renew until 05/16/2013 10:30:40

Kerberos:
krb5-1.11.2-4.fc19

--- Additional comment from Aleš Mareček on 2013-05-09 05:44:11 EDT ---

Workaround:
mkdir /run/usr/1000/krb5cc
chown -R <user><user> /run/usr/1000/krb5cc
kinit <user>@<kdc>
<password>

--- Additional comment from Aleš Mareček on 2013-05-09 05:44:52 EDT ---

*chown -R <user>:<user> ...

--- Additional comment from Patrik Kis on 2013-05-09 07:46:27 EDT ---

[root@pkisf19 ~]# rm -rf /run/user/0/
[root@pkisf19 ~]# 
[root@pkisf19 ~]# kinit Administrator@AD.BASEOS.QE
kinit: Credential cache directory /run/user/0/krb5cc does not exist while getting default ccache

--- Additional comment from Nalin Dahyabhai on 2013-05-09 11:43:14 EDT ---

(In reply to comment #1)
> I hit this bug by doing kinit as non-root user:
> 
> $ kinit Bender@AD.BASEOS.QE
> kinit: Credential cache directory /run/user/1000/krb5cc does not exist while
> getting default ccache

How was your shell started?  Under most conditions I'd expect pam_systemd to have created /run/user/$UID as part of setting up the user's session.

(In reply to comment #4)
> [root@pkisf19 ~]# rm -rf /run/user/0/

$XDG_RUNTIME_DIR typically points to this directory.  If it does, it's expected to be there.

--- Additional comment from Nalin Dahyabhai on 2013-05-09 13:27:10 EDT ---

(In reply to comment #0)
> I'm trying to 'kinit -k' as root, and I get this message about my credential
> cache directory not existing. 
> 
> [stef@stef ~]$ sudo kinit Administrator@BORG.THEWALTER.LAN
> kinit: Credential cache directory /run/user/0/krb5cc does not exist while
> getting default ccache

This one's thornier, as sudo doesn't open a session unless the -i flag is used, so pam_systemd wouldn't always be run if we added it to the PAM configuration for sudo.  If it did, the per-user temporary directory would also, by default, be cleaned up immediately after kinit exited.  But then pam_systemd also registers the login session using the process's loginuid, which is that of the invoking user (and which I'm guessing isn't supposed to be changed by sudo).

I don't see a general solution to this that makes this work for sudo along with other things; we'll probably have to patch sudo specifically.

--- Additional comment from Nalin Dahyabhai on 2013-05-09 14:04:03 EDT ---

(In reply to comment #6)
> sudo doesn't open a session unless the -i flag is used

Whoops, yes it does.

--- Additional comment from Simo Sorce on 2013-05-09 19:01:39 EDT ---

(In reply to comment #4)
> [root@pkisf19 ~]# rm -rf /run/user/0/
> [root@pkisf19 ~]# 
> [root@pkisf19 ~]# kinit Administrator@AD.BASEOS.QE
> kinit: Credential cache directory /run/user/0/krb5cc does not exist while
> getting default ccache


krb5 1.10 will not create the ccdir for you, 1.11 should do it.

--- Additional comment from Nalin Dahyabhai on 2013-05-10 15:54:21 EDT ---

(In reply to comment #8)
> (In reply to comment #4)
> > [root@pkisf19 ~]# rm -rf /run/user/0/
> > [root@pkisf19 ~]# 
> > [root@pkisf19 ~]# kinit Administrator@AD.BASEOS.QE
> > kinit: Credential cache directory /run/user/0/krb5cc does not exist while
> > getting default ccache
> 
> krb5 1.10 will not create the ccdir for you, 1.11 should do it.

Even 1.11 will only create the directory itself (/run/user/0/krb5cc).  For most users, though, removing /run/user/$UID isn't going to be allowed by filesystem permissions, so I'm less concerned about it being removed than it not being created in the first place.

--- Additional comment from Patrik Kis on 2013-05-14 11:10:10 EDT ---

Sorry for late response, I didn't realized that there was a progress in this bug.

(In reply to comment #5)
> (In reply to comment #1)
> > I hit this bug by doing kinit as non-root user:
> > 
> > $ kinit Bender@AD.BASEOS.QE
> > kinit: Credential cache directory /run/user/1000/krb5cc does not exist while
> > getting default ccache
> 
> How was your shell started?  Under most conditions I'd expect pam_systemd to
> have created /run/user/$UID as part of setting up the user's session.

The shell was stared by su (the same with sudo); and it seems this is the problem:

[root@pkis ~]# su - test
Last login: Tue May 14 16:31:24 CEST 2013 on pts/1
[test@pkis ~]$ echo $XDG_RUNTIME_DIR
/run/user/0
[test@pkis ~]$ id
uid=1001(test) gid=1001(test) groups=1001(test) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[test@pkis ~]$ ll /run/user/1001
ls: cannot access /run/user/1001: No such file or directory

But when it is stared by ssh (or login from console) it's ok:
$ ssh test@192.168.100.19
test@192.168.100.19's password: 
Last login: Tue May 14 16:35:36 2013
[test@pkis ~]$ echo $XDG_RUNTIME_DIR
/run/user/1001
[test@pkis ~]$ ll /run/user/1001
total 0
[test@pkis ~]$ 

So it seems that a bugs for su/sudo have to be opened.

> 
> (In reply to comment #4)
> > [root@pkisf19 ~]# rm -rf /run/user/0/
> 
> $XDG_RUNTIME_DIR typically points to this directory.  If it does, it's
> expected to be there.

--- Additional comment from Patrik Kis on 2013-05-17 04:50:36 EDT ---

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #4)
> > > [root@pkisf19 ~]# rm -rf /run/user/0/
> > > [root@pkisf19 ~]# 
> > > [root@pkisf19 ~]# kinit Administrator@AD.BASEOS.QE
> > > kinit: Credential cache directory /run/user/0/krb5cc does not exist while
> > > getting default ccache
> > 
> > krb5 1.10 will not create the ccdir for you, 1.11 should do it.
> 
> Even 1.11 will only create the directory itself (/run/user/0/krb5cc).  For
> most users, though, removing /run/user/$UID isn't going to be allowed by
> filesystem permissions, so I'm less concerned about it being removed than it
> not being created in the first place.

I'm a bit confused. I'm using krb5-1.11.2-5.fc19 and the /run/user/$UID directory is not created by kerberos. I tried:

[root@pkis ~]# env |grep XDG_RUNTIME_DIR
XDG_RUNTIME_DIR=/run/user/0
[root@pkis ~]# ls /run/user/0
ls: cannot access /run/user/0: No such file or directory
(reverse-i-search)`j': ^Curnalctl -f
[root@pkis ~]# kinit Bender@AD.BASEOS.QE
kinit: Credential cache directory /run/user/0/krb5cc does not exist while getting default ccache
[root@pkis ~]# 

Or when/how this should be created.

I see still two problems here and not quite sure where/how it should be fixed:

1/ After su/sudo login /run/user/$UID is not created. Who supposed to create it? sudo/su(pam) or kerberos

2/ Kerberos relays on value XDG_RUNTIME_DIR, which is not updated after su/sudo login. This seems to be clearly problem in su/sudo or maybe pam.

--- Additional comment from Patrik Kis on 2013-05-21 10:18:28 EDT ---

Hi Nalin,

Please ignore my previous comments; I was confused a bit.
It's clear that the $ID directory under /run/user should be create by the tool that manages the login process (su/sudo etc). The directory like /run/user/0/krb5cc/ again should be created by kerberos and it seems the kerberos tools handle this (I've tested most of command line tools, like kinit, kadmin, etc).

As far as the login tools concerns bug are filed against su and sudo and they will be fixed hopefully.
I have still one specific case though. Our automated tests are executed by daemons running on the system and like that there is no physical user logged in (particularly root). Therefore the directory /run/user/0 is missing and all our kerberos tests are failing when running kadmin, kinit, etc. The tests can be modified in a way that the required directory is created, but there is a question whether this directory shouldn't be created rather automatically (either by kinit,kadmin, etc for the calling user or precreated for every user that has running process (systemd?) ). The main question is if there is other use case than automated tests, if there may be other daemons that need to have /run/user/$ID created for user. Any thought, ideas?

So far it seems to me only kerberos command line tools require this directory, so that's the reason I'm asking you.

--- Additional comment from Simo Sorce on 2013-05-21 11:15:49 EDT ---

/run/user/0 should probably be precreated at system boot.
not sure what tool shoul do it, either systemd or tmpfiles.d script ?

--- Additional comment from Nalin Dahyabhai on 2013-05-21 14:24:40 EDT ---

I'm not overly familiar with processes which run as root and which operate as clients which would need credential caches -- my guess is that most of those cases, among things that we ship, are probably only concerned about filesystem access, and their needs are handled as special cases by rpc.gssd or gssproxy.

I don't think that a tmpfiles.d-based attempt would prevent logind from removing the directory if the root user logged in properly and then logged out.

--- Additional comment from Nalin Dahyabhai on 2013-05-21 17:45:49 EDT ---

Hmm, so based on a reading of bug #965419, the lifecycle /run/user/$LOGINUID is more or less bound to the audit session, and su and sudo have no effect on that.

--- Additional comment from Stef Walter on 2013-05-22 08:55:54 EDT ---

(In reply to Nalin Dahyabhai from comment #14)
> I'm not overly familiar with processes which run as root and which operate
> as clients which would need credential caches 

realmd does, for instance.

--- Additional comment from Simo Sorce on 2013-05-22 09:01:02 EDT ---

Stef, in general applications that run as root should be run by setting a specific KRB5CCNAME variable unless they are meant to modify the interactive root user ccache. (like kinit, klist, kvno).

Any other application should probably use a separate ccache.

Not sure what to make of "sudo kinit", it makes little sense to me. However sudo -i should create the /run/user/0/krb5cc dir if it is not already available IMO.

--- Additional comment from Stef Walter on 2013-05-22 09:18:39 EDT ---

(In reply to Simo Sorce from comment #17)
> Stef, in general applications that run as root should be run by setting a
> specific KRB5CCNAME variable unless they are meant to modify the interactive
> root user ccache. (like kinit, klist, kvno).
> 
> Any other application should probably use a separate ccache.

Yes, that's what realmd 'the daemon' does.

> Not sure what to make of "sudo kinit", it makes little sense to me. However
> sudo -i should create the /run/user/0/krb5cc dir if it is not already
> available IMO.

It totally makes sense to do things like this:

$ sudo -s
# kinit admin@blah.com
# realm join blah.com

Or the similar:

sudo -- sh -c 'kinit admin@blah.com; realm join blah.com'

Especially if you want to use non-password credentials to do a domain join.

The samba equivalent is:

$ sudo -s
# kinit admin@blah.com
# net join ads -k blah.com

Not being able to use kinit within a normal sudo command is pretty broken for lots of use cases.

--- Additional comment from Simo Sorce on 2013-05-22 13:13:42 EDT ---

There is a way to tell systemd to not destroy the user directory at session logout but I forgot what it is.
Maybe we can special case root this way and create the dir with tmpfiles.d, it would allow all the sudo scenarios to work properly.

--- Additional comment from Nalin Dahyabhai on 2013-05-22 17:55:30 EDT ---

(In reply to Simo Sorce from comment #19)
> There is a way to tell systemd to not destroy the user directory at session
> logout but I forgot what it is.

That'd be "loginctl enable-linger root".  I think you lose out on it ever being pruned, though.

--- Additional comment from Simo Sorce on 2013-05-23 16:45:41 EDT ---

Isn't it pruned at reboot given /run is a tmpfs ?
(reason why I say we also need tmpfiles.d)

--- Additional comment from Nalin Dahyabhai on 2013-05-23 17:55:53 EDT ---

Yes.  The linger option also results in it being re-created at boot, though, which is handy because tmpfiles.d configuration appears to be handled before /run is mounted on my test box.

--- Additional comment from Simo Sorce on 2013-05-24 09:40:49 EDT ---

(In reply to Nalin Dahyabhai from comment #22)
> Yes.  The linger option also results in it being re-created at boot, though,

Great, even better.

> which is handy because tmpfiles.d configuration appears to be handled before
> /run is mounted on my test box.

Sounds like a bug, I recall other programs creating directories there, heck tmpfiles.d reason of existence is to recreate directories on tmpfs filesystems, especially /run, so this makes no sense ... is this a bug in f19/rawhide ?

--- Additional comment from Patrik Kis on 2013-05-27 06:45:08 EDT ---

(In reply to Simo Sorce from comment #23)
> (In reply to Nalin Dahyabhai from comment #22)
> > Yes.  The linger option also results in it being re-created at boot, though,
> 
> Great, even better.
> 
> > which is handy because tmpfiles.d configuration appears to be handled before
> > /run is mounted on my test box.
> 
> Sounds like a bug, I recall other programs creating directories there, heck
> tmpfiles.d reason of existence is to recreate directories on tmpfs
> filesystems, especially /run, so this makes no sense ... is this a bug in
> f19/rawhide ?

On my F19 machine I was able to create directories with tmpfiles.d in /run itself but not in /run/user, so I would say that /run/user is created later, but I don't know what creates it.
Anyhow, it seems all configuration I've checked in tmpfiles.d creates application specific files/directories and no user specific, what /run/user/0 is. So it is really better to create it by the linger option of systemd.
I verified it and it works as expected; thanks to figuring this out. It just should be enabled by default for user root, so the automated test can be executed without changes. This would also help for sudo case, as you wrote (not the sudo executed by root and want to run task as non-root user, like # sudo -u dumyuser CMD).

--- Additional comment from Patrik Kis on 2013-05-27 06:46:51 EDT ---

Filed bug for RHEL-7.0 to precreate the /run/user/0 directory during the first boot: bug 967509

--- Additional comment from Alexander Bokovoy on 2013-06-05 08:48:48 EDT ---

(In reply to Simo Sorce from comment #17)
> Stef, in general applications that run as root should be run by setting a
> specific KRB5CCNAME variable unless they are meant to modify the interactive
> root user ccache. (like kinit, klist, kvno).
> 
> Any other application should probably use a separate ccache.
In FreeIPA case we need to modify the interactive root user ccache for 'ipa-adtrust-install'. Since ipa-adtrust-install must be run as root (it modifies Samba configuration via databases which only accessible to root), and end result of the ipa-adtrust-install is that KDC starts attaching MS-PAC to tickets, and those tickets required by smbd for trust setup, admin will have to  re-init the ticket to have MS-PAC in it.

That is why we don't use private ccache in ipa-adtrust-install.

--- Additional comment from Stef Walter on 2013-06-12 12:05:17 EDT ---

So how are we going to fix this in Fedora 19?

--- Additional comment from Nalin Dahyabhai on 2013-06-13 13:47:33 EDT ---

For the general case, the only complete solution is to enable lingering for accounts which are accessed using su and sudo, but we can't do that within this package.

Anything else (for example, having libkrb5 create the directory if it's /run/user/0, which is the only case where it would have permissions to do so) leaves us open to surprises if a such a user opens a full login session and then logs off, at which point logind will wipe the directory.

--- Additional comment from Patrik Kis on 2013-06-14 03:00:20 EDT ---

I have opened this systemd bug 967509 for RHEL-7 to enalble lingering for root by default. I'm not sure if systemd is the right component, maybe it should be done directly in anaconda, but the bug can forwarded any time.
This will enable root lingering only. Maybe we should consider to enable it to all user by default when user accounts are created; the main question is whether it has any drawbacks.

--- Additional comment from Martin Kosek on 2013-06-26 02:48:35 EDT ---
Comment 2 Martin Kosek 2013-07-17 03:53:39 EDT
This is not a bug in IPA, moving to krb5 component (the same component as the original Bug 961235).
Comment 4 Nalin Dahyabhai 2013-07-19 16:53:48 EDT
As noted above, a general fix isn't something I know how to do in here without replicating the privileged-server-being-asked-to-do-something part of the pam_systemd/logind combination that handles this most of the time.  But we'll at least be able to paper over it for the specific case of user 0 in krb5-1.11.3-4.el7.
Comment 5 Scott Poore 2013-09-11 11:22:16 EDT
Quick check on a test box of mine and this appears to be fixed:

[root@rhel7-5 user]# rpm -qf /usr/bin/kinit
krb5-workstation-1.11.3-9.el7.x86_64

[root@rhel7-5 user]# rm -rf /run/user/0

[root@rhel7-5 user]# pwd
/run/user

[root@rhel7-5 user]# ls

[root@rhel7-5 user]# kinit
kinit: Configuration file does not specify default realm when parsing name root

[root@rhel7-5 user]# find .
.
./0
./0/krb5cc
./0/krb5cc/primary

So, looks like I can probably remove the IPA tests workaround that pre-creates that.
Comment 6 Xiyang Dong 2013-09-26 12:03:06 EDT
issue reappears in newest krb5 :

[root@nec-em9 ~]# rpm -qf /usr/bin/kinit 
krb5-workstation-1.11.3-14.el7.x86_64

[root@nec-em9 ~]# klist -l
klist: No credentials cache found while getting default ccache

[root@nec-em9 ~]# rm -rf /run/user/0

[root@nec-em9 ~]# kinit admin
kinit: Credential cache directory /run/user/0/krb5cc does not exist while getting default ccache
Comment 8 Nalin Dahyabhai 2013-10-18 13:53:45 EDT
Originally this was only going to be something we tweaked while the default was DIR:, but I guess we need it.  Made it unconditional as of krb5-1.11.3-16.el7.
Comment 10 Scott Poore 2013-11-04 12:28:32 EST
Nalin,

Does this mean the default is back to something more like this?

FILE:/tmp/krb5cc_$(id -u)

That's what it seems like from a quick check:

[root@rhel7-1 user]# rpm -qf /usr/bin/klist
krb5-workstation-1.11.3-27.el7.x86_64

[root@rhel7-1 user]# unset KRB5CCNAME

[root@rhel7-1 user]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

[root@rhel7-1 user]# kinit admin
Password for admin@IPA1.EXAMPLE.TEST: 

[root@rhel7-1 user]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@IPA1.EXAMPLE.TEST

Valid starting       Expires              Service principal
11/04/2013 11:26:20  11/05/2013 11:26:18  krbtgt/IPA1.EXAMPLE.TEST@IPA1.EXAMPLE.TEST


Thanks,
Scott
Comment 11 Nalin Dahyabhai 2013-11-04 14:19:51 EST
(In reply to Scott Poore from comment #10)
> Nalin,
> 
> Does this mean the default is back to something more like this?
> 
> FILE:/tmp/krb5cc_$(id -u)

No, the configured default should be KEYRING:persistent:%{uid}.  Is there a value set for "default_ccache_name" in your /etc/krb5.conf's [libdefaults] section?

> That's what it seems like from a quick check:
> 
> [root@rhel7-1 user]# rpm -qf /usr/bin/klist
> krb5-workstation-1.11.3-27.el7.x86_64

The configuration file is owned by krb5-libs.  Please check its version, and if you upgraded from a previous version of the package, if a trigger to edit the file and add the default would have been invoked as part of the upgrade from that previous version.
Comment 12 Scott Poore 2013-11-04 14:57:47 EST
(In reply to Nalin Dahyabhai from comment #11)
> (In reply to Scott Poore from comment #10)
> > Nalin,
> > 
> > Does this mean the default is back to something more like this?
> > 
> > FILE:/tmp/krb5cc_$(id -u)
> 
> No, the configured default should be KEYRING:persistent:%{uid}.  Is there a
> value set for "default_ccache_name" in your /etc/krb5.conf's [libdefaults]
> section?

No, doesn't look like it:

[root@rhel7-5 conf.d]# grep default_ccache_name /etc/krb5.conf
[root@rhel7-5 conf.d]# 

> 
> > That's what it seems like from a quick check:
> > 
> > [root@rhel7-1 user]# rpm -qf /usr/bin/klist
> > krb5-workstation-1.11.3-27.el7.x86_64
> 
> The configuration file is owned by.  Please check its version, and
> if you upgraded from a previous version of the package, if a trigger to edit
> the file and add the default would have been invoked as part of the upgrade
> from that previous version.

[root@rhel7-5 conf.d]# rpm -q krb5-libs
krb5-libs-1.11.3-27.el7.x86_64

No upgrade from what I can tell.  Looks like was built with that version:

[root@rhel7-5 log]# grep -i "INFO packaging: krb5-libs" /var/log/anaconda/anaconda.packaging.log 
19:57:48,698 INFO packaging: krb5-libs-1.11.3-27.el7.x86_64 (136/298)
Comment 13 Nalin Dahyabhai 2013-11-04 15:28:38 EST
(In reply to Scott Poore from comment #12)
> No upgrade from what I can tell.  Looks like was built with that version:
> 
> [root@rhel7-5 log]# grep -i "INFO packaging: krb5-libs"
> /var/log/anaconda/anaconda.packaging.log 
> 19:57:48,698 INFO packaging: krb5-libs-1.11.3-27.el7.x86_64 (136/298)

Is the file being overwritten at some point, then?  I just checked the package payload with rpm2cpio, and it is in the included krb5.conf, as intended.
Comment 14 Scott Poore 2013-11-04 23:30:43 EST
(In reply to Nalin Dahyabhai from comment #13)
> (In reply to Scott Poore from comment #12)
> > No upgrade from what I can tell.  Looks like was built with that version:
> > 
> > [root@rhel7-5 log]# grep -i "INFO packaging: krb5-libs"
> > /var/log/anaconda/anaconda.packaging.log 
> > 19:57:48,698 INFO packaging: krb5-libs-1.11.3-27.el7.x86_64 (136/298)
> 
> Is the file being overwritten at some point, then?  I just checked the
> package payload with rpm2cpio, and it is in the included krb5.conf, as
> intended.

Oh yeah, it's overwritten by the ipa-server-install isn't it?  From /usr/share/ipa/krb5.conf.template?

[root@rhel7-1 ~]# grep default_ccache_name /usr/share/ipa/krb5.conf.template 
[root@rhel7-1 ~]# 

Should the IPA template be modified there?
Comment 15 Alexander Bokovoy 2013-11-05 00:12:10 EST
Yes, for distributions where KEYRING ccache type is available.
Comment 16 Scott Poore 2013-11-05 10:11:15 EST
Ok, I opened bug #1026861 for IPA krb5.conf.template file.  

For this, if I manually add back default_ccache_name to /etc/krb5.conf:
...
[libdefaults]
 default_realm = IPA1.EXAMPLE.TEST
 dns_lookup_realm = false
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = yes
 default_ccache_name = KEYRING:persistent:%{uid}

...

[root@rhel7-1 ~]# kdestroy

[root@rhel7-1 ~]# klist
klist: No credentials cache found while retrieving principal name

[root@rhel7-1 ~]# kinit admin
Password for admin@IPA1.EXAMPLE.TEST: 

[root@rhel7-1 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@IPA1.EXAMPLE.TEST

Valid starting       Expires              Service principal
11/05/2013 09:04:22  11/06/2013 09:04:21  krbtgt/IPA1.EXAMPLE.TEST@IPA1.EXAMPLE.TEST

So, that's back to expected I think...now on to check out the cache dir /run/user/0 issue:

[root@rhel7-1 ~]# env |grep XDG_RUNTIME_DIR
XDG_RUNTIME_DIR=/run/user/0

[root@rhel7-1 ~]# cd /run/user/0
-bash: cd: /run/user/0: No such file or directory

[root@rhel7-1 ~]# export KRB5CCNAME=DIR:/run/user/0/krb5cc

[root@rhel7-1 ~]# kdestroy
kdestroy: No credentials cache found while destroying cache

[root@rhel7-1 ~]# klist
klist: No credentials cache found (ticket cache DIR::/run/user/0/krb5cc/tkt)

[root@rhel7-1 ~]# kinit admin
Password for admin@IPA1.EXAMPLE.TEST: 

[root@rhel7-1 ~]# cd /run/user/0/
[root@rhel7-1 0]# ls
krb5cc
[root@rhel7-1 0]# cd krb5cc/

[root@rhel7-1 krb5cc]# ls
primary  tkt

So, I do think that looks better.

Thanks,
Scott
Comment 17 Nalin Dahyabhai 2013-11-05 11:06:11 EST
This is all a workaround for the default location not being there all of the time, but we're not using that default any more.  Given that we don't have privileges to do the same for other UIDs, is there a reason we should still be doing this?
Comment 18 Scott Poore 2013-11-05 11:40:41 EST
Actually, isn't the fix useful for other users if cache location set somewhere outside of run?

[root@rhel7-1 root]# su - mytest 
Last login: Tue Nov  5 10:33:44 CST 2013 on pts/0
su: warning: cannot change directory to /home/mytest: No such file or directory

-sh-4.2$ export KRB5CCNAME=DIR:/tmp/mytestkcc

-sh-4.2$ kinit mytest
Password for mytest@IPA1.EXAMPLE.TEST: 

-sh-4.2$ klist
Ticket cache: DIR::/tmp/mytestkcc/tkt
Default principal: mytest@IPA1.EXAMPLE.TEST

Valid starting       Expires              Service principal
11/05/2013 10:34:16  11/06/2013 10:34:14  krbtgt/IPA1.EXAMPLE.TEST@IPA1.EXAMPLE.TEST

So, looks like it could be useful in some cases still.  Or is it something else handling creating those dirs and the previous fix here just handled /run/user/0?

I guess I'm just trying to determine what is expected here so we can accurately help verify the bug.

Thanks,
Scott
Comment 20 Ludek Smid 2014-06-13 06:00:03 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.