Description of problem: After installation of current FC 17, configured with users $HOME to be on an AFS volume, local logins fail to get an openafs token, so that the user can't access his $HOME. I did a klist, and got above error message, so I checked the permissions of the users credentials cache and saw that it was owned by root:root, instead of being owned by the user. If, OTOH, I simulate a remote login via "ssh localhost", the user can login without problem, because the credentials cache file is correctly owned by the user. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Setup the machine as kerberos client. 2. Login locally (either console or graphically). 3. Actual results: User can't access credentials cache file, klist gives above error message. Expected results: User can access credentials cache file, klist should list users tickets. Additional info:
How did you log in (at the console, via sshd, using one of the desktop managers (and if so, which one))? Where was the credential cache created (i.e., what was your $KRB5CCNAME set to when you logged in)? What was logged to /var/log/secure at the time you logged in?
(In reply to comment #1) > How did you log in (at the console, via sshd, using one of the desktop > managers (and if so, which one))? Logins on the console succeed in so far, that I get a prompt. But due to the wrong credentials cache file permissions, I don't get an AFS token to enter $HOME. KDM logins fail completely because of the inability to access $HOME. Remote logins via ssh succeed with correct credentials cache permissions, means I also get the AFS token and can access $HOME as usual. > Where was the credential cache created (i.e., what > was your $KRB5CCNAME set to when you logged in)? In both cases it was created in /tmp: % ll /tmp/krb5cc_1000_* -rw-------. 1 root root 510 18. Mai 12:01 /tmp/krb5cc_1000_E6wy0Z -rw-------. 1 heini users 936 18. Mai 12:10 /tmp/krb5cc_1000_wZGv49 > What was logged to > /var/log/secure at the time you logged in? KDM: May 18 11:59:57 moria kdm: :0[841]: pam_unix(kdm:session): session opened for user root by (uid=0) May 18 12:00:26 moria polkitd(authority=local): Registered Authentication Agent for unix-session:1 (system bus name :1.26 [/usr/libexec/kde4/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) May 18 12:00:51 moria unix_chkpwd[1185]: password check failed for user (heini) May 18 12:00:51 moria kdm: :1[1173]: pam_unix(kdm:auth): authentication failure; logname= uid=0 euid=0 tty=:1 ruser= rhost= user=heini May 18 12:00:51 moria kdm: :1[1173]: pam_krb5[1173]: TGT verified using key for 'host/moria.altum.de' May 18 12:00:52 moria kdm: :1[1173]: pam_krb5[1173]: authentication succeeds for 'heini' (heini) May 18 12:00:52 moria kdm: :1[1173]: pam_unix(kdm:session): session opened for user heini by (uid=0) May 18 12:00:55 moria kdm: :1[1173]: pam_unix(kdm:session): session closed for user heini Console login: May 18 12:01:36 moria unix_chkpwd[1295]: password check failed for user (heini) May 18 12:01:36 moria login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=heini May 18 12:01:36 moria login: pam_krb5[1293]: TGT verified using key for 'host/moria.altum.de' May 18 12:01:36 moria login: pam_krb5[1293]: authentication succeeds for 'heini' (heini) May 18 12:01:37 moria login: pam_unix(login:session): session opened for user heini by LOGIN(uid=0) May 18 12:01:37 moria login: LOGIN ON tty2 BY heini SSH: May 18 12:10:49 moria unix_chkpwd[1476]: password check failed for user (heini) May 18 12:10:49 moria sshd[1474]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=heini May 18 12:10:49 moria sshd[1474]: pam_krb5[1474]: TGT verified using key for 'host/moria.altum.de' May 18 12:10:49 moria sshd[1474]: pam_krb5[1474]: authentication succeeds for 'heini' (heini) May 18 12:10:49 moria sshd[1474]: Accepted password for heini from 127.0.0.1 port 45921 ssh2 May 18 12:10:49 moria sshd[1474]: pam_unix(sshd:session): session opened for user heini by (uid=0) As you can see, it reports success in all three cases :(
(In reply to comment #2) > (In reply to comment #1) > > Where was the credential cache created (i.e., what > > was your $KRB5CCNAME set to when you logged in)? > > In both cases it was created in /tmp: > > % ll /tmp/krb5cc_1000_* > -rw-------. 1 root root 510 18. Mai 12:01 /tmp/krb5cc_1000_E6wy0Z > -rw-------. 1 heini users 936 18. Mai 12:10 /tmp/krb5cc_1000_wZGv49 The first one is from the console login, the second one from the ssh login.$KRB5CCNAME was correctly set to these files in both cases.
Reassigning to pam_krb5, then.
*** Bug 824819 has been marked as a duplicate of this bug. ***
Any update on that?
It looks like login is doing a pam_setcred() to reinitialize credentials after it's opened the session. The module typically interprets this as a "you're in a screensaver-type-application, so update the existing credential cache with those new credentials you just got" signal, and promptly rewrites the user's credential cache. It doesn't drop privileges when it does this, though, and login is still running as root when it calls into PAM to do this, so the newly-recreated credential cache is owned by root instead of the target user. Good times. Leaving aside whether or not login should have started to do this, handling this so that the right SELinux context is assigned to the resulting ccache is annoyingly complicated -- I don't think a simple fork and dropping of privileges (which is what git master now does) is going to achieve the right results in MLS deployments, though it seems to be good enough for my unconfined user. That may have to be good enough for the moment, though, until a more-work-but-better fix is done. If you're in a position to grab the master branch (http://git.fedorahosted.org/git/pam_krb5.git) to see if it works correctly in your setup, it'd be useful to know.
pam_krb5-2.3.14-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/pam_krb5-2.3.14-1.fc17
In general, the updated package helps 'a bit'. The file permissions are now set correctly, but I still got an SELinux denial. t_r:local_login_tmp_t:s0 tclass=file type=AVC msg=audit(1338374716.823:1583): avc: denied { read } for pid=19940 comm="klist" name="krb5cc_44805_CNF3Hg" dev="sda1" ino=16646246 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:local_login_tmp_t:s0 tclass=file type=AVC msg=audit(1338374716.823:1583): avc: denied { open } for pid=19940 comm="klist" name="krb5cc_44805_CNF3Hg" dev="sda1" ino=16646246 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:local_login_tmp_t:s0 tclass=file type=AVC msg=audit(1338374716.823:1584): avc: denied { lock } for pid=19940 comm="klist" path="/tmp/krb5cc_44805_CNF3Hg" dev="sda1" ino=16646246 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:local_login_tmp_t:s0 tclass=file type=AVC msg=audit(1338374823.261:1599): avc: denied { write } for pid=19971 comm="kdestroy" name="krb5cc_44805_CNF3Hg" dev="sda1" ino=16646246 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:local_login_tmp_t:s0 tclass=file type=AVC msg=audit(1338374823.261:1600): avc: denied { unlink } for pid=19971 comm="kdestroy" name="krb5cc_44805_CNF3Hg" dev="sda1" ino=16646246 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:local_login_tmp_t:s0 tclass=file Besides that it's still not possible to mount a CIFS Share with cifs.upcall: mount error(126): Required key not available
The latter is likely a cifs.upcall problem when trying to mount a DFS CIFS share. I am going to open a separate bug on that.
The SELinux problem has been reported by my workmate and is fixed now: https://bugzilla.redhat.com/show_bug.cgi?id=826444
I'd attempted to cancel the update because the smaller change didn't fix things properly. Are you saying that with the updated policy, things work correctly for your confined users?
In general the permissions are set correctly with this and the SELinux fix. The DFS problem is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=826507
pam_krb5-2.3.14-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.