Bug 116198

Summary: The realm directive is not honoured if pam_krb5 is called twice in the PAM stack
Product: [Fedora] Fedora Reporter: Carlos A. Villegas <villegas>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: 2.1.2-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-31 10:46:54 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
sample /etc/pam.d/gdm file
sample /etc/krb5.conf
relevant syslog entries for the failed login attempt described
patch (hack) to get it working
patch modified with the suggestion by wolfe+rhbz@ems.psu.edu none

Description Carlos A. Villegas 2004-02-18 17:53:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; Linux i686; U) Opera 7.21  [en]

Description of problem:

When using pam_krb5 twice on the stack, to authenticate users against 
one of two possible realms the second invocation of the module won't 
be able to initialize the pricipal in the right realm.

This setup works fine with the previous version (pam_krb5-2.0.4-1). 
I'm attaching some sample config files that show the problematic 
setup, as well as the logs from a failed login attempt, that shows 
the problem. 

If I may be so bold as to suggest a place to look it is src/userinfo.
c, but I'm not familiar enough with the code to try a patch. 

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

How reproducible:

Steps to Reproduce:
1. setup two mutually untrusted realms (KDC), I call them EXAMPLE1.
COM and EXAMPLE2.COM in the attached config files
2. on the client use attached krb5.conf
3. on the client set up pam for some service as attached
4. try to log in with a principal from the second realm that will be 
tried (In the examples I'm sending, it is  user@EXAMPLE2.COM)

Actual Results:  
The user will not be authenticated, since it will try to authenticate 
user@EXAMPLE1.COM (instead of user@EXAMPLE2.COM).

Expected Results:  
Authentication should be successful if proper credentials for that 
realm are presented.

Additional info:

I'll also attach the relevant logs from an attempt as described.
Comment 1 Carlos A. Villegas 2004-02-18 17:59:20 EST
Created attachment 97815 [details]
sample /etc/pam.d/gdm file
Comment 2 Carlos A. Villegas 2004-02-18 18:00:11 EST
Created attachment 97816 [details]
sample /etc/krb5.conf
Comment 3 Carlos A. Villegas 2004-02-18 18:00:40 EST
Created attachment 97817 [details]
relevant syslog entries for the failed login attempt described
Comment 4 Carlos A. Villegas 2004-08-05 16:07:42 EDT
Created attachment 102470 [details]
patch (hack) to get it working

By doing this change, I got it to work, however I'm not sure why it didn't work
in the first place, and don't know if there are other implications that I
didn't notice.
Comment 5 Carlos A. Villegas 2004-08-05 16:13:27 EDT
Actually, I did have to use the realm option on both calls, like so:

auth       sufficient   /lib/security/pam_krb5.so no_user_check
use_first_pass realm=EXAMPLE1.COM
auth       sufficient   /lib/security/pam_krb5.so no_user_check
realm=EXAMPLE2.COM use_first_pass

Otherwise the realm was still wrong for the one call that didn't
specify it, however the context initialization seems to be fine and
I'm not sure why the problem happens in the first place...

Comment 6 Jeff Wolfe 2004-08-26 16:25:31 EDT
I'm not sure this will work correctly. This line in the patch:

        /* Use the local user name which the user gave us. */
-       strncpy(local_name, name, sizeof(local_name) - 1);
+       strncpy(local_name, full_principal, sizeof(local_name) - 1);
        local_name[sizeof(local_name) - 1] = '\0';

Doesn't produce a working setup on my test machine. I had to switch
"full_principal" back to "name" to get something that worked.

Otherwise, it seems to work fine, and solves a problem we have on RHEL
3 and FC 2 machines. This should be backported to RHEL3, In my search
for a fix for this, I found a lot of people asking about it, but no
Comment 7 Carlos A. Villegas 2004-08-27 16:17:20 EDT
Great!! I didn't notice that, that fixed a problem I had with the
patch,  that required me to use the no_user_check option. I'll post
the actual patch that works fine in a moment (it simply removes that
change), it is against 2.0.10-1. Any chances of that getting back into
the real sources? In the meantime I added that patch to an "internal"
rpm that has a greater revision than 1...

Comment 8 Carlos A. Villegas 2004-08-27 16:19:52 EDT
Created attachment 103183 [details]
patch modified with the suggestion by wolfe+rhbz@ems.psu.edu

This seems to work fine with the minimal testing I've made. Patch against
Comment 9 Nalin Dahyabhai 2004-08-31 10:46:54 EDT
Patch incorporated for 2.1.2.  Thanks!