It appears to me that mod_auth_pam (other PAM modules?) violates the PAM architecture as specified in:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-3.html
Specifically, rather than going through PAM modules as specified in the pam.d configuration file (e.g. pam.d/httpd in the case I am focusing on), mod_auth_pam punches through directly to base underlying Unix calls including getpwnam and getgrnam (calls that don't lay on top of PAM) for parts of its function.
The consequence of this bypassing of the PAM architecture/modules is that one can set up what would otherwise be a working independent authentication mechanism through PAM (e.g. pam_ldap in my case) only to have it end up requiring lower level unix configuration (e.g. nss) to function. This means that any such lower level unix configuration is forced into a system, polluting what would otherwise be a clean separation.
The specific case I'm dealing with is mod_auth_pam and pam_ldap. I set things up and configure /etc/pam.d/httpd as:
account required /lib/security/pam_permit.so < Not sure why this is required
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_deny.so
As I understand the PAM architecture (as on the diagram above) this should work
to use with apache authentication being forwarded to LDAP. However, I found that
I needed to include:
passwd: files ldap group: files ldap
in my /etc/nsswitch.conf file to get it to function. This meant I couldn't use it in my system as it forced all sorts of LDAP users and groups to be on the system (e.g. for login, file access, etc., etc.) that should not be on the system.
Puzzled, I looked at mod_auth_pam.c (1.1.1) and found:
418: pwent = getpwnam(r->connection->user); and 464: if ((grent = getgrnam (groupname)) && grent->gr_mem) {
It is these calls that seem to me to effectively punch through PAM and go to what one might in PAM terminology call pam_unix. That is, they drop down past the PAM stack directly to the underlying Unix calls. It is these calls that depend on nss (e.g. nsswitch.conf) to find content outside the local files - e.g. in my case in LDAP.
This seems to me to be an incorrect implementation. At least it seems not to follow the PAM architecture and to be ineffective for many applications - e.g. like mine.
I spent some time looking through the pam-list archives for discussion on this topic. I saw a number of messages with questions prompted by issues similar to the problem I was having. I also found a couple that seemed to be addressing themselves to the base architectural issue, like:
http://www.redhat.com/archives/pam-list/2001-June/msg00020.html
but nothing that seems to focus on the problems of such punching through to the lower level unix authentication (e.g. nss).
To solve my practical problem I found that I could remove the call to pwent = getpwnam(r->connection->user); from mod_auth_pam.c (I also had to replace some later references to the returned username with the previously available r->connection->user ). This change solved the most important practical part of my problem, namely I was able to change my nsswitch.conf to:
passwd: files group: files ldap
This at least got the LDAP users out of my underlying system, though the groups visible through LDAP are still (sadly) there (e.g. one can see them with getent group <group name>).
One issue with the change as I did it is that if a user has a default group in "/etc/passwd" but not in the corresponding entry in /etc/group (both coming from LDAP in my case, but I hope the idea is clear) then group authentication will fail. In my case I want to require users be in the LDAP groups for authentication to succeed, so this works for me.
I'm not sure if my changes may have introduced other problems, but my testing didn't show up any.
From my perspective mod_auth_pam (other PAM modules?) is simply broken and should be fixed. If lib_nss can get passwd and group information from LDAP it seems to me mod_auth_pam should be able to get such information via PAM to LDAP (or whatever).
I'd be interested to hear what others think. Is this punching through considered a bug or a feature? Has there been previous discussion on this topic that I missed?
--Jed http://www.nersc.gov/~jed/
_______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list