This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 116198 - The realm directive is not honoured if pam_krb5 is called twice in the PAM stack
The realm directive is not honoured if pam_krb5 is called twice in the PAM stack
Product: Fedora
Classification: Fedora
Component: pam_krb5 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2004-02-18 17:53 EST by Carlos A. Villegas
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 2.1.2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-31 10:46:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample /etc/pam.d/gdm file (1.01 KB, text/plain)
2004-02-18 17:59 EST, Carlos A. Villegas
no flags Details
sample /etc/krb5.conf (594 bytes, text/plain)
2004-02-18 18:00 EST, Carlos A. Villegas
no flags Details
relevant syslog entries for the failed login attempt described (2.99 KB, text/plain)
2004-02-18 18:00 EST, Carlos A. Villegas
no flags Details
patch (hack) to get it working (1.78 KB, patch)
2004-08-05 16:07 EDT, Carlos A. Villegas
no flags Details | Diff
patch modified with the suggestion by (1.53 KB, patch)
2004-08-27 16:19 EDT, Carlos A. Villegas
no flags Details | Diff

  None (edit)
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/ no_user_check
use_first_pass realm=EXAMPLE1.COM
auth       sufficient   /lib/security/ 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

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!

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