PAM modules violating PAM architecture?, e.g. mod_auth_pam

[Jed Donnelley]

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/