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
