[OpenAFS-devel] Current pthread PAM patch for Debian

Jeffrey Hutzelman jhutz@cmu.edu
Mon, 29 Aug 2005 00:18:18 -0400


On Sunday, August 28, 2005 20:02:09 -0700 Russ Allbery <rra@stanford.edu> 
wrote:

> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
>
>> However, the OpenAFS PAM modules are normally built against the LWP
>> versions of the libraries, not the pthread ones.  I'm not entirely sure
>> what Russ's motivation is in wanting pthread versions of the PAM modules
>> (maybe there's a Debian policy, or maybe they have a threaded app that
>> uses PAM), but it's not currently a necessary part of an OpenAFS
>> platform port.
>
> Threaded app that uses PAM.  (sshd, in particular.)

Ugh.  Of course, sshd is not _actually_ a threaded app -- it starts up 
pthreads for the exclusive purpose of running pam_authenticate in a 
separate thread, in order to work around an architecture that would 
otherwise make conversation.... annoying (though not impossible).

Maybe one of these days I'll see if I can come up with a proper fix to that 
problem that doesn't involve running pam_authenticate in a separate thread 
or, worse, a separate process.


>> So, assuming you're happy using the LWP versions of the libraries, there
>> is a much simpler (and, for the moment, more maintainable) solution
>> available to you than what Russ is doing.  Simply arrange to have
>> src/cf/osconf.m4 set CCOBJ to include the flags necessary to build PIC
>> code on your platform.  See the amd64_linux* stanza as an example.
>
> Note that this builds everything PIC; I'm not sure if you care.  My
> understanding is that there's a minor performance penalty.  I'm not sure
> if anything AFS does is such that you'd notice.

Last I checked, only those objects actually needed for the PAM module were 
built with $(CCOBJ).  Maybe that changed when I wasn't looking.  In any 
event, I'd be surprised to find a situation in which this has significant 
impact.

-- Jeff