Bug 371761
| Summary: | credcache created for root, not user, when establishing credentials | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas R. <redhat-bugs> | ||||||
| Component: | pam_krb5 | Assignee: | 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 | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 2.2.21 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-11-09 22:27:15 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 252021 [details]
relevant part of /var/log/messages, IPs/hostnames edited out
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 "no_user_check"? 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. 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.
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 NI-TUEBINGEN.DE' to 'krbtgt/STUDENT.UNI-TUEBINGEN.DE.DE' Nov 8 22:30:23 sshd[11275]: pam_krb5[11275]: pkinit identity has no contents, ignoring Nov 8 22:30:23 sshd[11275]: pam_krb5[11275]: krb5_get_init_creds_password(krbt gt/STUDENT.UNI-TUEBINGEN.DE.DE) returned 0 (Success) 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.DE': user disallowed by .k5login file for 'zxmoo46' Nov 8 22:30:23 sshd[11275]: pam_krb5[11275]: authentication fails for 'zxmoo46' (zxmoo46.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). 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. 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. 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.
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... :-) 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! |
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): pam-krb5-2.2.20-1 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 #%PAM-1.0 #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: #[appdefaults] # 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 no_user_check auth sufficient pam_krb5.so realm=UNI-TUEBINGEN.DE use_first_pass debug no_user_check auth sufficient pam_krb5.so realm=STUDENT.UNI-TUEBINGEN.DE use_first_pass debug no_user_check 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.