Subject: Re: integrating PAM
To: None <>
From: Jed Davis <>
List: current-users
Date: 01/22/2003 16:58:22
On Wed, Jan 22, 2003 at 02:10:57AM -0500, Aidan Cully wrote:
> The thing that really irritated me about PAM (this is a fuzzy memory
> from at least three years ago) was that the external API was defined,
> but I didn't see any documentation on actually creating the PAM
> modules, and got the distinct impression that the internal API was
> not standardized...  I.e., it would be impossible to use the same
> source code to generate a PAM module for all the PAM-providing
> platforms (Linux, Solaris, etc.).  Can someone correct me on this?

There's one quote from the _Linux-PAM Application Developers' Guide_
that comes to mind; the context is the "conversation function"
provided by the application to the modules, which the modules can
call back to have the application do one of: prompt for a string with
echo on, prompt for a string with echo off, display an error, or
display an informational message ($DEITY help you if you're writing a
single-threaded, event-driven GUI program, though).  The comment is

} In passing, it is worth noting that there is a descrepency between the
} way Linux-PAM handles the const struct pam_message **msg conversation
} function argument from the way that Solaris' PAM (and derivitives,
} known to include HP/UX, are there others?) does. Linux-PAM interprets
} the msg argument as entirely equivalent to the following prototype
} const struct pam_message *msg[] (which, in spirit, is consistent
} with the commonly used prototypes for argv argument to the familiar
} main() function: char **argv; and char *argv[]). Said another way
} Linux-PAM interprets the msg argument as a pointer to an array
} of num_meg read only 'struct pam_message' pointers. Solaris' PAM
} implementation interprets this argument as a pointer to a pointer to
} an array of num_meg pam_message structures. Fortunately, perhaps, for
} most module/application developers when num_msg has a value of one
} these two definitions are entirely equivalent. Unfortunately, casually
} raising this number to two has led to unanticipated compatibility
} problems.


<?xml version="1.0"?>  <?xml-stylesheet href=""
type="text/xsl"?>   <sig name="Jed Davis">  <id dom="" lp="sjld8197">
Student, 4th-Year</id><id dom="" lp="jldavis">CS Major and Student
SysAdmin</id><id dom="" lp="jdev">Panixer</id> <q href="bin.q"/> </sig>