On 2001-10-26 at 13:35:50 Nicolas Williams <Nicolas.Williams@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@redhat.com> wrote:
> On Wojtek Pilorz <wpilorz@bdk.pl> wrote:
> > On Wed, 5 Sep 2001, Nalin Dahyabhai wrote:
> > > Date: Wed, 5 Sep 2001 17:31:10 -0400
> > > From: Nalin Dahyabhai <nalin@redhat.com>
> > > To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
> > > Cc: openssh-unix-dev@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.
--
