Re: [mituc@xxxxxxxxxxxxxx: pam limits drops privileges]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 06, 2001 at 09:36:37AM -0400, Nalin Dahyabhai wrote:
> On Thu, Sep 06, 2001 at 09:50:46AM +0200, Olaf Kirch wrote:
> > Sounds strange to me... but I'm forwarding it here in case you
> > haven't seen it yet.
> 
> Looking at it, I'm surprised it doesn't happen more often.  Most
> modules which perform user or group lookups use the non-threaded
> functions (getpwnam(), getgrnam(), etc.), which have to be screwing
> with applications one way or another.

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.

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.

> 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.

-- 
/sd





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux