In this case it could be simpler to fix the applications
themselves. I remember being very careful when PAM-ifying
some of the Darwin (OS X) applications to avoid this particular
issue. (Darwin unfortunately does not have the reentrant
getpw* APIs. Actually, I did implement them but Apple never
integrated them.)
cheers,
-- Luke
>From: Nalin Dahyabhai <nalin@redhat.com>
>Subject: Re: [mituc@iasi.rdsnet.ro: pam limits drops privileges]
>To: pam-list@redhat.com
>Date: Fri, 7 Sep 2001 16:30:50 -0400
>Organization: Red Hat, Inc.
>
>On Fri, Sep 07, 2001 at 07:09:51AM +0400, Solar Designer wrote:
>> None of the programs involved are multi-threaded. Of course, it is
>> quite likely that one or more of them have bugs where they assume
>> get{pw,gr}*() output buffers stay the same over pam_*() calls. Of
>> course it would be better if our PAM modules actually were thread-
>> safe. I just don't see why you conclude any of this is relevant to
>> the described behavior.
>
>I suspect that many programs involved assume that the output buffers
>aren't going to be changed across calls into PAM, and depend on that
>being the case to work properly.
>
>> What do you think is the communication medium between the sshd and
>> the login? I'd suspect either permissions on a tty or a [uw]tmp
>> entry, and would think from there.
>
>By default, sshd doesn't spawn a copy of login, so most of the
>processing is done inside of the parent sshd, before it forks off a
>child to handle the user's session.
>
>Since I couldn't reproduce the reported behavior on my development
>box, it's hard for me to pin down why the end-user is seeing it.
>
>> > I'd suggest reworking most of them to use getpwnam_r and friends,
>> > which appear to be standardized at least in SUSv2.
>>
>> I agree. And Linux-PAM could provide an autoconf test and wrapper
>> functions for systems which lack the reentrant interfaces. In fact,
>> I'd want the wrapper functions to be placed in the public domain.
>
>I hadn't been suggesting wrappers, but a patch would have been fairly
>large (touching every module).
>
>The logic for handling failures with ERANGE (buffer too small) errors
>complicates things, but considering the idea, wrapping them in functions
>would localize all of that. The wrapper could even allocate a buffer
>which is stored as a pam data item (with a cleanup function which frees
>the buffer later on). This would make the wrappers less portable out of
>the PAM tree, but much more useful, I think.
>
>Nalin
>
>
>
>_______________________________________________
>
>Pam-list@redhat.com
>https://listman.redhat.com/mailman/listinfo/pam-list
--
Luke Howard | lukehoward.com
PADL Software | www.padl.com
