Bug 371761 - credcache created for root, not user, when establishing credentials
Summary: credcache created for root, not user, when establishing credentials
Alias: None
Product: Fedora
Classification: Fedora
Component: pam_krb5
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-08 19:53 UTC by Thomas R.
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version: 2.2.21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-09 22:27:15 UTC

Attachments (Terms of Use)
relevant part of /var/log/messages, IPs/hostnames edited out (24.13 KB, text/plain)
2007-11-08 19:53 UTC, Thomas R.
no flags Details
patch for 2.2.20 which fetches tokens before calling krb5_kuserok() (6.37 KB, patch)
2007-11-09 21:06 UTC, Nalin Dahyabhai
no flags Details | Diff

Description Thomas R. 2007-11-08 19:53:07 UTC
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 = cs.uni-tuebingen.de
#     ccache_dir = /tmp
#   }

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

auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth 
auth  sufficient pam_krb5.so realm=CS.UNI-TUEBINGEN.DE      use_first_pass debug
auth  sufficient pam_krb5.so  realm=UNI-TUEBINGEN.DE        use_first_pass debug
auth  sufficient pam_krb5.so realm=STUDENT.UNI-TUEBINGEN.DE use_first_pass debug
auth       required     pam_deny.so

[... account, password...]

session    required     pam_limits.so
session    required     pam_unix.so
session optional pam_krb5.so realm=CS.UNI-TUEBINGEN.DE      debug
session optional pam_krb5.so realm=UNI-TUEBINGEN.DE         debug
session optional pam_krb5.so 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 19:53:08 UTC
Created attachment 252021 [details]
relevant part of /var/log/messages, IPs/hostnames edited out

Comment 2 Nalin Dahyabhai 2007-11-08 21:09:25 UTC
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 21:41:22 UTC
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 22:22:08 UTC
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-09 01:06:28 UTC
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 19:39:53 UTC
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 19:56:01 UTC
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 21:06:15 UTC
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 22:09:10 UTC
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 22:23:59 UTC
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!

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