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_krb5 | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.1.2-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-08-31 14:46:54 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 97815 [details]
sample /etc/pam.d/gdm file
Created attachment 97816 [details]
sample /etc/krb5.conf
Created attachment 97817 [details]
relevant syslog entries for the failed login attempt described
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.
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 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.
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 Created attachment 103183 [details]
patch modified with the suggestion by wolfe+rhbz.edu
This seems to work fine with the minimal testing I've made. Patch against
2.0.10-1.
Patch incorporated for 2.1.2. Thanks! |
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) Actual Results: The user will not be authenticated, since it will try to authenticate user (instead of user). 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.