This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 822493 - klist: Credentials cache permissions incorrect while setting cache flags
klist: Credentials cache permissions incorrect while setting cache flags
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pam_krb5 (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
: 824819 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-17 10:15 EDT by Dirk Heinrichs
Modified: 2013-08-01 14:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 14:46:42 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 Dirk Heinrichs 2012-05-17 10:15:41 EDT
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:
Comment 1 Nalin Dahyabhai 2012-05-17 11:14:04 EDT
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?
Comment 2 Dirk Heinrichs 2012-05-18 06:18:54 EDT
(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@ALTUM.DE'
May 18 12:00:52 moria kdm: :1[1173]: pam_krb5[1173]: authentication succeeds for 'heini' (heini@ALTUM.DE)
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@ALTUM.DE'
May 18 12:01:36 moria login: pam_krb5[1293]: authentication succeeds for 'heini' (heini@ALTUM.DE)
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@ALTUM.DE'
May 18 12:10:49 moria sshd[1474]: pam_krb5[1474]: authentication succeeds for 'heini' (heini@ALTUM.DE)
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 :(
Comment 3 Dirk Heinrichs 2012-05-18 06:22:46 EDT
(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.
Comment 4 Nalin Dahyabhai 2012-05-18 11:26:30 EDT
Reassigning to pam_krb5, then.
Comment 5 Nalin Dahyabhai 2012-05-24 15:18:15 EDT
*** Bug 824819 has been marked as a duplicate of this bug. ***
Comment 6 Marcus Moeller 2012-05-29 07:23:52 EDT
Any update on that?
Comment 7 Nalin Dahyabhai 2012-05-29 11:27:13 EDT
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.
Comment 8 Fedora Update System 2012-05-29 13:34:08 EDT
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
Comment 9 Marcus Moeller 2012-05-30 07:13:42 EDT
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
Comment 10 Marcus Moeller 2012-05-30 07:32:33 EDT
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.
Comment 11 Marcus Moeller 2012-05-31 02:47:28 EDT
The SELinux problem has been reported by my workmate and is fixed now:

https://bugzilla.redhat.com/show_bug.cgi?id=826444
Comment 12 Nalin Dahyabhai 2012-05-31 11:46:04 EDT
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?
Comment 13 Marcus Moeller 2012-06-04 05:00:53 EDT
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
Comment 14 Fedora Update System 2012-06-22 04:33:55 EDT
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.
Comment 15 Fedora End Of Life 2013-07-04 03:03:04 EDT
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.
Comment 16 Fedora End Of Life 2013-08-01 14:46:47 EDT
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.

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