[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