Description of problem: Trying to kinit for the first time from a fresh install of F18 on my laptop fails with: [jwboyer@zod log]$ kinit jboyer kinit: Credential cache directory /run/user/1000/krb5cc_d816341cad0f9ecbdd905de150abb00e does not exist while getting default ccache [jwboyer@zod log]$ Version-Release number of selected component (if applicable): krb5-workstation-1.10.3-5.fc18.x86_64 I copied /etc/krb5.conf from an existing machine, but it doesn't reference a specific ccache location so it should just use the defaults. My environment variables show: KRB5CCNAME=DIR:/run/user/1000/krb5cc_d816341cad0f9ecbdd905de150abb00e what sets this, I have no idea. I understand the DIR: thing is a new F18 feature, and that's fine but I don't think a user is expected to create the directory manually. Particularly when it involves a rather non-human friendly hash thing at the end they'd have no awareness of beforehand. strace seems to just show normal looking kinit things going on, with a stat to the directory getting ENOENT and then it exiting. /run/user/1000/ exists, but not the krb5cc_d816341cad0f9ecbdd905de150abb00e directory.
Adding Steve on CC since he's the F18 feature owner.
This directory is supposed to be created by libkrb5 as long as the user has write permission on the parent directory (/run/user/1000 in this case). /run/user/1000 is generated by systemd during session startup and should have the appropriate permissions. Josh, can you check whether there's an SELinux denial occurring here?
(In reply to comment #2) > This directory is supposed to be created by libkrb5 as long as the user has > write permission on the parent directory (/run/user/1000 in this case). > /run/user/1000 is generated by systemd during session startup and should > have the appropriate permissions. Should be fine permissions wise: [jwboyer@zod log]$ ls -l /run/user total 0 drwx------. 6 jwboyer jwboyer 140 Nov 30 11:44 1000 [jwboyer@zod log]$ > Josh, can you check whether there's an SELinux denial occurring here? Sorry, should have mentioned that too. I don't see anything in /var/log/messages, dmesg, or /var/log/audit/audit.log that would indicate an SELinux denial. I can attach the full strace if you would like.
Created attachment 658365 [details] strace output of 'kinit jboyer' (In reply to comment #3) > I can attach the full strace if you would like. Sorry, FESCo meeting got in the way. Attached.
(In reply to comment #2) > This directory is supposed to be created by libkrb5 as long as the user has > write permission on the parent directory (/run/user/1000 in this case). That won't happen until krb5 1.11.
(In reply to comment #5) > (In reply to comment #2) > > This directory is supposed to be created by libkrb5 as long as the user has > > write permission on the parent directory (/run/user/1000 in this case). > > That won't happen until krb5 1.11. OK. So what is supposed to create it now?
Well, I rebooted the latop in question and kinit works fine now. Nothing changed other than the reboot. I have no idea what is _supposed_ to create that directory and why it didn't before, but things appear to work fine now. If you'd like to close the bug, feel free.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #2) > > > This directory is supposed to be created by libkrb5 as long as the user has > > > write permission on the parent directory (/run/user/1000 in this case). > > > > That won't happen until krb5 1.11. > > OK. So what is supposed to create it now? The application which sets $KRB5CCNAME is expected to ensure that the directory is there, as the hard-wired default for the library is still to use FILE:/tmp/krb5cc_$UID, which doesn't require additional setup. I realize you said that you're not seeing a failure here any more, but for the sake of curiosity, what's your $KRB5CCNAME set to? If it's of the form DIR:/run/user/$UID/krb5cc_(32 hex digits), then it's gnome-online-accounts.
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #2) > > > > This directory is supposed to be created by libkrb5 as long as the user has > > > > write permission on the parent directory (/run/user/1000 in this case). > > > > > > That won't happen until krb5 1.11. > > > > OK. So what is supposed to create it now? > > The application which sets $KRB5CCNAME is expected to ensure that the > directory is there, as the hard-wired default for the library is still to > use FILE:/tmp/krb5cc_$UID, which doesn't require additional setup. > > I realize you said that you're not seeing a failure here any more, but for > the sake of curiosity, what's your $KRB5CCNAME set to? If it's of the form > DIR:/run/user/$UID/krb5cc_(32 hex digits), then it's gnome-online-accounts. It's changed since the initial value I put in the opening comment of this bug, but it's still a DIR: KRB5CCNAME=DIR:/run/user/1000/krb5cc_54277058aaab9e64369ed70950c4a371 So... weird.
That suffix is a GUID which should correlate to the value used in $DBUS_SESSION_BUS_ADDRESS, and is set by gdm (specifically, gdm-session-worker). I can confirm that the current F18 package creates the directory before setting the environment variable to point to it, so it looks like we can move this to gdm and mark it closed. Thanks!