Description of problem: When using pam_oddjob_mkhomedir.so on a system with SELinux disabled, the following errors appear when using "su": Error org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown: Could not determine security context for ':1.586' Otherwise everything works OK. Version-Release number of selected component (if applicable): oddjob-0.27-9.el5 How reproducible: always Steps to Reproduce: 1. Disable SELinux 2. Add to /etc/pam.d/system-auth: session required pam_oddjob_mkhomedir.so 3. Restart the messagebus and oddjobd services 4. su - some_user, where some_user's home doesn't exist yet Actual results: Error org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown: Could not determine security context for ':1.1'. Creating home directory for some_user Expected results: Creating home directory for some_user Additional info: I think oddjob shouldn't ask for SELinux context on a system where SELinux is disabled.
Created attachment 351039 [details] Proposed patch
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0668.html
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the oddjob_request and pam_oddjob_mkhomedir.so clients would print an error message, when running on systems on which SELinux had been disabled. This was because these clients could not determine the SELinux context of the running oddjobd daemon. With this update, the clients do not attempt to do so anymore and the issue is resolved.