Bug 163445 - sshd interacts badly with pam_limits.so
sshd interacts badly with pam_limits.so
Product: Fedora Legacy
Classification: Retired
Component: openssh (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Fedora Legacy Bugs
Depends On:
  Show dependency treegraph
Reported: 2005-07-16 17:25 EDT by David Warme
Modified: 2007-04-18 13:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-16 18:15:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Warme 2005-07-16 17:25:38 EDT
Description of problem:
When we upgraded from openssh*-3.6.1p2-19 to the recent
patch openssh*-3.6.1p2-19.2.legacy we were no longer
able to use SSH to login, except as root.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Apply the stated patch to Fedora Core 1
2. Try to login using ssh.
Actual results:
Connection closed by remote host after entering my password.

Expected results:
Normally would expect to login and receive a shell prompt.

Additional info:

Problem occurs because sshd version 3.6.1p2-19 did not run
"niced", whereas sshd version 3.6.1p2-19.2.legacy does run
"niced" to level 10.  This interacts badly with the
pam_limits.so module.

I did an strace on the sshd process to try and figure out what was
going on.  What I discovered was that the system call

    setpriority (PRIO_PROCESS, 0, 0);

(apparently called from the pam_limits.so module in order to set
the default "nice" priority of zero) was failing because the
sshd process now runs at a "nice" value of 10 instead of 0,
and only the superuser can decrease the priority of a process.
This apparently causes the pam_limits.so module to return an
error code.  Our PAM configuration provides this configuration
for sshd (completely vanilla Fedora Core 1, I believe):

auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    required     pam_limits.so
session    optional     pam_console.so

Changing the pam_limits line from "required" to "optional"
restored our ability to login.  This might have other
adverse effects, however.

Although I have worked around this problem, I am reporting it
because others who install the same patch might find
themselves being locked out from logging in via SSH.

If you are going to make sshd run "niced", then you should
probably "unnice" child processes as they are created -- or
at least "unnice" them before invoking pam_open_session().
Comment 1 Jesse Keating 2005-07-16 17:45:00 EDT
Is it an initscript that is setting the nice level?  Check /etc/init.d/sshd or
/etc/sysconfig/ssh or something like that.  Strange that this would change....
Comment 2 David Warme 2005-07-16 18:04:43 EDT
I just checked the SSH source code, and could not find anywhere that
called "nice()" or "setpriority()".  I then looked at the sshd process
that was actually running -- it had a nice value of zero -- NOT niced.

When I initially started my investigation, sshd definitely had a
"nice" value of 10.  Furthermore, sshd was actually running at the
time I launched the "up2date" process to apply the patched version
of ssh.  Once the patch was applied (I assume that applying the
patch caused the existing sshd process to be stopped and restarted),
I was no longer able to login with ssh.  To the best of my knowledge,
this process was not stopped or restarted until well into my
investigations (i.e., I suspect that the "nice" of 10 was applied
by the patch logic (as invoked from the up2date GUI app).

Once I discovered what was going on, I modified the /etc/pam.d/sshd
file and re-tried the login.  It was still failing.  So I did an
"sh /etc/rc.d/init.d/sshd restart", and it started working again.
The new sshd process had a "nice" value of zero again!  Setting
the /etc/pam.d/sshd "pam_limits" line back to "required" is no
longer required.

I suspect that the "nice 10" sshd process occurred because of the
environment inherited from the "up2date" GUI app.  Care to wager
25 cents or so?
Comment 3 David Warme 2005-07-16 18:07:54 EDT
Ooops -- let me correct that:

Once I restarted sshd, it is no longer necessary for the
pam_limits line in /etc/pam.d/sshd to say "optional" -- it
seems to work fine in the original state of "required".
Comment 4 Jesse Keating 2005-07-16 18:15:21 EDT
Strange, however I can't see how this is a bug in SSH.  Perhaps up2date, which
we aren't supporting.

Note You need to log in before you can comment on or make changes to this bug.