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

Re: [mituc@iasi.rdsnet.ro: pam limits drops privileges]

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


-- 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.
>Pam-list mailing list

Luke Howard | lukehoward.com
PADL Software | www.padl.com

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