pam_limits module bug and its effects on pam applications

[Joachim Falk]

On 2001-10-26 at 13:35:50 Nicolas Williams <Nicolas.Williams at ubsw.com> wrote:
> On Fri, Oct 26, 2001 at 02:11:13PM +0200, Markus Friedl wrote:
> > On Fri, Oct 26, 2001 at 10:14:21AM +1000, Damien Miller wrote:
> > > On Thu, 25 Oct 2001, Ed Phillips wrote:
> > >
> > > > What is the reasoning behind this?  Do we want to see a lastlog entry for
> > > > "ssh" whenever a user runs remote command?  Do other OSes have
> > > > pam_open_session that does more meaningful things than Solaris 8?
> > > > Well...  I guess the more I think about it, it's probably better to go
> > > > ahead an call pam_open_session even for the non-interactive case since
> > > > someone might want to implement a PAM module at their site that logs every
> > > > ssh connection... and if we don't call pam_open_session, then they don't
> > > > even have that capability if they wanted it.
> > >
> > > Some people set rlimits using session modules. Someone even filed a Bugtraq
> > > report about it.
> >
> > is this the right way?
>
> It's *a* right way.
>
> > isn't this an abuse of the PAM module? (perhaps file a Bugtraq report...)
>
> Why would it be?

On 2001-09-07 at 21:21:10 Nalin Dahyabhai <nalin at redhat.com> wrote:
> On Wojtek Pilorz <wpilorz at bdk.pl> wrote:
> > On Wed, 5 Sep 2001, Nalin Dahyabhai wrote:
> > > Date: Wed, 5 Sep 2001 17:31:10 -0400
> > > From: Nalin Dahyabhai <nalin at redhat.com>
> > > To: Ognyan Kulev <ogi at fmi.uni-sofia.bg>
> > > Cc: openssh-unix-dev at mindrot.org
> > > Subject: Re: pam_limits and OpenSSH
> > >
> > > On Wed, Sep 05, 2001 at 04:53:05PM +0300, Ognyan Kulev wrote:
> > > > Perhaps the daemon first sets process limits and then switches to the
> > > > user and/or fork().  But fork() cannot succeed because there is a
> > > > process number limit to 40 that is applied to root.  This is my
> > > > hypothesis.  I didn't look at sources.  What you think about all this?
> > > > Do you need more information?  I use Debian GNU/Linux potato and OpenSSH
> > > > 1.2.3-9.3.
> > >
> > > This is exactly the case.  The process limit is set while the server
> > > is still running as the superuser, so it can't fork() to start the
> > > child (which would then do a setuid() to the user's ID).
> > >
> > > Opening the PAM session after performing the fork() and setuid() fixes
> > > this for pam_limits, but breaks other modules which expect to be running
> > > with superuser privileges when their pam_open_session() handlers are
> > So what about opening PAM session after performing fork but before
> > setuid() ? Would it be correct ?
> It's been a while since I looked at what's going on in that area of
> the tree, but IIRC the child exec()s the user's shell, and opening
> the session in the child makes it difficult for the parent to close
> the session when the user logs out.  This depends on which modules
> are in use, though -- some modules handle this sort of situation
> just fine, while others will just fail.
> >
> > > called.  This was the crux of the whole pam_open_session mess from a few
> > > months ago -- my apologies for setting it in motion.
> > >
> > > Other process limits are going to have similar effects on sshd, and I
> > > don't see a clean way to handle process limits within PAM in this case.
> > >
> > > Hope this cleared things up a bit,
> > >
> > > Nalin
> > >
> > Best regards,

A pam module which sets resource limits in pam_sm_open_session is
just inherently broken. There is no way to fulfill 2 contradictory
requirements to make this work.

We have the following requirements:

1) pam_sm_open_session & pam_sm_close_session
	must be called as root
> > > Opening the PAM session after performing the fork() and setuid() fixes
> > > this for pam_limits, but breaks other modules which expect to be running
> > > with superuser privileges when their pam_open_session() handlers are

2) pam_sm_open_session & pam_sm_close_session
	must be called in the same process
> It's been a while since I looked at what's going on in that area of
> the tree, but IIRC the child exec()s the user's shell, and opening
> the session in the child makes it difficult for the parent to close
> the session when the user logs out.  This depends on which modules
> are in use, though -- some modules handle this sort of situation
> just fine, while others will just fail.

The contradictory requirement:
3) There must not be a fork as root after calling pam_sm_open_session
> > > > Perhaps the daemon first sets process limits and then switches to the
> > > > user and/or fork().  But fork() cannot succeed because there is a
> > > > process number limit to 40 that is applied to root.  This is my
> > > > hypothesis.  I didn't look at sources.  What you think about all this?
> > > > Do you need more information?  I use Debian GNU/Linux potato and OpenSSH
> > > > 1.2.3-9.3.

I suggest to fix pam_limits to implement limits setting in pam_sm_setcred:
The flow would than be:

   parent:					child:
   (sshd daemon)				(sshd daemon later
						 user shell/command)
  pam_start
     |
     v
  pam_authenticate
     |
     v
  pam_open_session
     |
     v
    fork ------------------------------------------+
     |						   |
     v                                             v
  wait for child to finish			pam_setcred to establish credentials
     |						   |
     v						   v
  pam_close_session				setuid/gid to authenticated user
     |						   |
     v						   v
  pam_setcred call to cleanup credentials	exec shell/command
     |
     v
  pam_end

But this requires that pam_setcred( pamh, PAM_ESTABLISH_CRED)
and pam_setcred( pamh, PAM_DELETE_CRED ) can be called in different
processes. If this is not the case i don't know of a way to ever
implement resource limit settings in a reliable way.

--