This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes

Bug 371761

Summary: credcache created for root, not user, when establishing credentials
Product: [Fedora] Fedora Reporter: Thomas R. <redhat-bugs>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 2.2.21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-09 17:27:15 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
relevant part of /var/log/messages, IPs/hostnames edited out
patch for 2.2.20 which fetches tokens before calling krb5_kuserok() none

Description Thomas R. 2007-11-08 14:53:07 EST
Description of problem:
When using pam_krb5 for sshd, the correct credential cache file gets created in
the session phase, but then, when sshd tells pam_krb5 to establish credentials,
a file for uid 0 gets created and ends up in the users environment.

The user we tested this with lives in ldap, krb and AFS.

Version-Release number of selected component (if applicable):

Actual results:
zxmoo46@host ~ $ ll /tmp/
insgesamt 24
-rw------- 1 root    csusers 1480  8. Nov 20:08 krb5cc_0_WmtMpE
-rw------- 1 zxmoo46 csusers 1480  8. Nov 20:08 krb5cc_786213_egrRPB
zxmoo46@host ~ $ klist
klist: krb5_cc_get_principal: open(/tmp/krb5cc_0_WmtMpE): Permission denied

Expected results:
krb5cc_786213_egrRPB should be the active ccache

Additional info:
We are using your 2.2.20 version on Gentoo Linux, as your pam module can take a
realm paramater and we have users from multiple realms. We use it like this:

# cat /etc/pam.d/system-auth

#This is a pam config working with several krb5 realms and one afs cell. The afs
cell, ccache_dir etc. is specified in /etc/krb5.conf:
# pam = {
#     ticket_lifetime = 36h
#     renew_lifetime = 0
#     forwardable = true
#     afs_cells =
#     ccache_dir = /tmp
#   }

#The pam_krb5 module is version 2.2.20 with heimdal (MIT should work also).

auth       required
auth       sufficient likeauth 
auth  sufficient realm=CS.UNI-TUEBINGEN.DE      use_first_pass debug
auth  sufficient  realm=UNI-TUEBINGEN.DE        use_first_pass debug
auth  sufficient realm=STUDENT.UNI-TUEBINGEN.DE use_first_pass debug
auth       required

[... account, password...]

session    required
session    required
session optional realm=CS.UNI-TUEBINGEN.DE      debug
session optional realm=UNI-TUEBINGEN.DE         debug
session optional realm=STUDENT.UNI-TUEBINGEN.DE debug

and this worked for openssh 4.5 and pam-krb5-2.2.6. Since upgrading to openssh
4.7, our test machine shows the described faulty behavior. Upgrading pam_krb5 to
2.2.20 didn't help (pam_krb5 doesn't delete the ccache file with the right
permissions any more, but the user env still points to the wrong file).

see attached /var/log/messages snippet for a debug log of whats happening. Note
that after the session setup everything is like it should be, but then sshd
notes "debug1: PAM: establishing credentials" and the file owned by root is created.

From my understanding, this could be related to bug #204939.

Fyi, that's our sshd_config:
Protocol 2
LogLevel debug 
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
TCPKeepAlive yes
UsePrivilegeSeparation yes
ClientAliveInterval 120
Subsystem       sftp    /usr/lib64/misc/sftp-server

Please get back if you need more info / want us to try a patch.
Comment 1 Thomas R. 2007-11-08 14:53:08 EST
Created attachment 252021 [details]
relevant part of /var/log/messages, IPs/hostnames edited out
Comment 2 Nalin Dahyabhai 2007-11-08 16:09:25 EST
The "no_user_check" option is probably causing this -- with it, pam_krb5 just
makes note of the current UID when it's called for the first time and uses that
instead of looking up the user's UID.  It probably makes sense for it to instead
use the current UID at the time the file's being created instead, but if sshd
isn't dropping its privileges before opening the PAM session or initializing the
PAM credentials, it won't change the visible behavior.  Can you run without
Comment 3 Thomas R. 2007-11-08 16:41:22 EST
Tricky. This is for a large number of hosts, and the KDC is a windows host,
where I don't know how to mass add hosts and export keytabs. But if you just
want to know if that indeed is causing our problem, I can test it for one host.
Comment 4 Nalin Dahyabhai 2007-11-08 17:22:08 EST
The "no_user_check" option shouldn't make a difference there -- I think you're
thinking of the "validate" option, which validates the user's credentials using
a local keytab file ("no_user_check" inhibits calls to getpwnam(), which
nss_ldap is servicing for you).  But yes, if it works correctly with
"no_user_check" turned off, I think that'll be the best thing to do.
Comment 5 Thomas R. 2007-11-08 20:06:28 EST
Ah, you're right, got it mixed up. Then it's even worse: the homes of the users
are on AFS, and with user_check enabled, I get this in /var/log/messages:

Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: KRB5CCNAME is not set, none found
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: trying previously-entered passwor
d for 'zxmoo46', allowing libkrb5 to prompt for more
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: authenticating 'zxmoo46@STUDENT.U
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: pkinit identity has no contents, 
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: krb5_get_init_creds_password(krbt
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: got result 0 (Success)
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: account checks fail for
'zxmoo46@STUDENT.UNI-TUEBINGEN.DE': user disallowed by .k5login file for 'zxmoo46'
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: authentication fails for
'zxmoo46' (zxmoo46@STUDENT.UNI-TUEBINGEN.DE): Permission denied (Success)
Nov  8 22:30:23  sshd[11275]: pam_krb5[11275]: pam_authenticate returning 6
(Permission denied)
Nov  8 22:30:26  sshd[11275]: debug1: PAM: password authentication failed for
zxmoo46: Authentication failure

And with knowing that, if I read the man page, it actually says why I have this
problem - it says it'll use the uid of the user run under with no_user_check,
and it also states it expects .k5login to be readable :/. Sorry for not noticing.

The thing is, no user has a .k5login, but local root may not enter
/home/$ANYUSER. Do I really have to add acls for user:root to all home
directories? I'd rather not.

I'd be nice if I could just disable the .k5login check, or the establish
credential pam phase (as session setup works fine if left alone).
Comment 6 Nalin Dahyabhai 2007-11-09 14:39:53 EST
I'm very confused by this -- I keep my home directory in AFS specifically so
that I can catch this stuff, and it's not supposed to fail like that.  Is there
any chance your user has a ~/.k5login.d directory?  Heimdal supports that as well.
Comment 7 Nalin Dahyabhai 2007-11-09 14:56:01 EST
Nope, I'm seeing this here now that I build with Heimdal, too.  The Kerberos
library is getting an EACCES error trying to read the user's .k5login file and
returning a failure, because it doesn't know that the file doesn't exist.
Comment 8 Nalin Dahyabhai 2007-11-09 16:06:15 EST
Created attachment 253501 [details]
patch for 2.2.20 which fetches tokens before calling krb5_kuserok()

Can you try adding the attached patch to 2.2.20?  It should ensure that the
module has tokens for the user before attempting to call krb5_kuserok(), so
that the module will be able to correctly handle whether or not the user has a
.k5login file.	If it's a success, I'll add it for 2.2.21.
Comment 9 Thomas R. 2007-11-09 17:09:10 EST
Yes, this works indeed (without "no_user_check")! Log looks good, too. I assume
this still has the side effect that users without homedir (or with the wrong
ACLs on it) can't log in?

Thanks for the fast response! I'd mark this as fixed, but your bugzie doesn't
seem to work like that... :-)
Comment 10 Nalin Dahyabhai 2007-11-09 17:23:59 EST
I haven't verified this, but that sounds like what would happen -- getting
tokens prevents EACCES when the user's tokens are sufficient for access to the
user's home directory, but if the ACLs are set to deny the user access anyway, I
think that error would still occur.

I'm going to roll that new release, and then close as resolved in Raw Hide.  Thanks!