openssh unix dev - Jan 2002 - [Bug 83] fork() fails when there are PAM limits set

http://bugzilla.mindrot.org/show_bug.cgi?id=83

djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.0.2p1                     |-current



------- Additional Comments From djm at mindrot.org  2002-01-31 21:46 -------
I'm putting some replies from the openssh-unix-dev mailing list into the bug
so
we capture the history in one place.

On Thu, 2002-01-31 at 21:11, Frank Cusack wrote:
> On Thu, Jan 31, 2002 at 09:54:36AM +0000, Matthew Vernon wrote:
> > My understanding of this is that it's a result of a fundamental
> > mis-design of PAM - you have to do the entire PAM conversation in one
> > go (as root), so this sort of PAM-based limiting is always going to be
> > prone to this sort of error.
> 
> I don't see how this is a problem with PAM?  You do have to do the
> entire conversation in one go, but not as root (other than a possible
> requirement for access to some resources like /etc/shadow -- but, eg,
> with krb5 you MUST NOT be root when doing PAM auth).  Regardless, why
> would PAM trip up here, and why would the conversation matter?  Limits
> such as described would not be managed during pam_authenticate() (when the
> conversation happens).  Perhaps I am not familiar enough with nuances
> of debian's PAM implementation.
The problem is that we call pam_session as root, before we fork the child.
Therefore the server picks up the limits, rather than the child. 

I recall that we tried moving the pam_session call to the child a while (~18
months) ago to avoid this problem, but other stuff broke much worse. IIRC the
breakage was because we did pam_session stuff in one process (as non-root) and
then did cleanup in another process (as root).

A possible way around this is with a gratuitous fork() before we call
pam_session, but that is pretty ugly.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.