Red Hat Bugzilla – Full Text Bug Listing
|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_krb5||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||2.1.2-1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-08-31 10:46:54 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): pam_krb5-2.0.5-1 How reproducible: Always 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... Carlos
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 answers.
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... Carlos
Comment 8 Carlos A. Villegas 2004-08-27 16:19:52 EDT
Created attachment 103183 [details] patch modified with the suggestion by firstname.lastname@example.org This seems to work fine with the minimal testing I've made. Patch against 2.0.10-1.
Comment 9 Nalin Dahyabhai 2004-08-31 10:46:54 EDT
Patch incorporated for 2.1.2. Thanks!