Bug 516761
Summary: | pam-logins don't work using rhnpush | ||
---|---|---|---|
Product: | [Community] Spacewalk | Reporter: | Sandro Mathys <sandro> |
Component: | Server | Assignee: | Jan Pazdziora (Red Hat) <jpazdziora> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Satellite QA List <satqe-list> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 0.6 | CC: | jmontleo, jpazdziora, marcus.moeller |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-02-08 08:42:18 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: | |||
Bug Depends On: | |||
Bug Blocks: | 653453 |
Description
Sandro Mathys
2009-08-11 12:42:39 UTC
I had the same problem and it appears to be selinux policy related. After running setenforce 0 and trying again I was able to generate the following in order to get it to work with selinux enforcing enabled. module rhnpush 1.0; require { type httpd_t; class netlink_audit_socket { write nlmsg_relay create read }; } #============= httpd_t ============== allow httpd_t self:netlink_audit_socket { write nlmsg_relay create read }; On our system, no SELinux denials are logged, neither on the client running rhnpush nor on the Satellite Server. This is logged on Satellite during login attempt: ('Password check failed (4): System error',) Best Regards Marcus I just retested this with rhncfg-manager (which used to have the same problem). Now it works if SELinux is permissive only but not in enforcing mode as described by Jason. Not sure what changed because SELinux hasn't been the (primary) problem before as Marcus reported. Oh, don't have anything around to try rhnpush right now to verify this observation is the same with both tools. By the way, using the API with a python script always works, just like the WebUI. Seeing that this might SELinux issue, I'm taking for investigation. Could you please paste your pam configuration? The PAM SELinux issues are often dependent on what authentication system you use (LDAP, Kerberos, ...), so knowing your setup will make it easier to reproduce it here. Thank you. Alright, here you go: [root@id-sws-prd-01 ~]# grep pam_auth_service /etc/rhn/rhn.conf pam_auth_service = rhn-satellite [root@id-sws-prd-01 ~]# cat /etc/pam.d/rhn-satellite #%PAM-1.0 auth required pam_env.so auth sufficient pam_ldap.so auth required pam_deny.so account required pam_ldap.so Didn't even know/remember that was so tiny. Let me know if you need anything else. In our case: #%PAM-1.0 auth required pam_env.so auth sufficient pam_krb5.so no_user_check auth required pam_deny.so account required pam_krb5.so no_user_check Mass-moving to space13. Sandro, I've checked that on Spacewalk nightly (with spacewalk-backend-1.3.50-1.el5) the rhnpush passes both with Kerberos and LDAP. Could you try on Spacewalk nightly (or wait for 1.3)? (In reply to comment #8) > Sandro, I've checked that on Spacewalk nightly (with > spacewalk-backend-1.3.50-1.el5) the rhnpush passes both with Kerberos and LDAP. > Could you try on Spacewalk nightly (or wait for 1.3)? I forgot: to get it to work, you need to upgrade the selinux-policy-targeted to the version from RHEL 5.6 or higher, and you need to set # setsebool allow_httpd_mod_auth_pam 1 This bug has been fixed in Spacewalk 1.3. |