Bug 539423 - pam_krb5 requires self principal to be listed in .k5login
Summary: pam_krb5 requires self principal to be listed in .k5login
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: krb5   
(Show other bugs)
Version: 5.6
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: BaseOS QE Security Team
Depends On:
Blocks: 646499
TreeView+ depends on / blocked
Reported: 2009-11-20 04:45 UTC by Jatin Nansi
Modified: 2018-11-14 18:31 UTC (History)
8 users (show)

Fixed In Version: krb5-1.6.1-54.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 612046 646499 650349 (view as bug list)
Last Closed: 2011-01-13 23:33:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0098 normal SHIPPED_LIVE krb5 bug fix and enhancement update 2011-01-12 17:39:25 UTC

Description Jatin Nansi 2009-11-20 04:45:35 UTC
Description of problem:
Customer is using Kerberos + ldap (AD) for authentication and authorization. They use the .k5login feature of kerberos for users to share privileges. It is by design that kerberos requires the principal sharing privileges to include his own principal name in the .k5login file if he wants to access his own resources. The customer feels that this behaviour is not correct.

The only use case where a user should be denied after presenting correct credentials is when a krb5 principal is to be specifically disallowed from logging in to a machine. Today, this is possible in a number of ways especially since PAM is used by all other unices like AIX, Solaris, HP-UX etc in addition to Linux.

So the design use-case has been clearly surpassed by other developments. There is no reason why the ~/.k5login should be checked at all if the correct credentials are presented. To disallow specific users, other more general methods like pam are available.

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

How reproducible:

Steps to Reproduce:
1. Set up a krb5 server
2. Set up a RHEL5 system that authenticates users using pam_krb5.
3. For a test user, create the .k5login file. Make sure root can read this file - sshd reads this file as root.
4. Try sshing in as the test user - login will fail.
5. Add user's principal to .k5login, login will succeed.
Actual results:
Login does not succeed unless users principal is added to .k5login file.

Expected results:
Login should succeed even when users principal is absent from .k5login file.

Additional info:
The customers use case also involves users home directories on NFS. If the home directory is shared root_squashed, ssh cannot read the .k5login file, in which case login succeeds. If ssh (root) can read .k5login, the user is not allowed to login.

Comment 1 Nalin Dahyabhai 2010-04-01 16:16:29 UTC
The root-squashing case is fixed in a later release (pam_krb5 drops the user's UID and creates a temporary ccache to hold the credentials for the sake of rpc.gssd, obtaining tokens if AFS is in play).  We can backport that and the recently-introduced configuration option to disable the checking of .k5login, but the behavior of the check itself is part of a libkrb5 API which I don't expect to change.

Comment 25 Anthony Messina 2010-11-05 19:48:13 UTC
This is also a problem in Fedora 14, upgrading from Fedora 13.

Comment 26 Nalin Dahyabhai 2010-12-02 22:23:15 UTC
Fedora 14 also has the k5login_authoritative setting available in krb5.conf, which is what's being backported to address this bug here.

Comment 28 errata-xmlrpc 2011-01-13 23:33:17 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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