Bug 174418 - sshd denies non-root logins when running "nice'd"
sshd denies non-root logins when running "nice'd"
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-11-28 15:43 EST by David Warme
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: openssh-3.9p1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-28 15:51:38 EST
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-11-28 15:43:02 EST
Description of problem:

When the "sshd" process is running "nice'd" (i.e., at reduced
priority), and it is configured to use Linux PAM, all logins
(otherwise valid) other than "root" are denied.

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

How reproducible:

Start a PAM-enabled sshd at "nice 10" and try to login.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

The default PAM script for "sshd" specifies module pam_limits.so,
which attempts to setpriority() to zero.  This fails if the sshd
process is already running at a priority level > 0 -- unless
it happens to be a super-user login, since only the super-user is
permitted to set a new priority level less than the current level.

In the present case the "sshd" process came to be running at a
nice level of 10 because the "up2date" GUI application applied an
openssh package update.  Since "up2date" runs at "nice 10", and the
openssh RPM causes any running "sshd" to be restarted as part of
the install process, this "sshd" received the "contagious" process
priority attribute of its parent.

I previously reported this bug as #163445.  The maintainer who was
assigned this previous bug report closed the case calling it NOTABUG.

Unfortunately, this "not-a-bug" has now skewered me once again!  The
only difference is that this time I only wasted 2 hours figuring out
what the problem was instead of 2 entire days!

I assure you -- this *is* a bug!  As currently configured,
openssh-server-3.6.1p2-19.2.legacy does not function correctly when
invoked in a "niced" state.  The sshd program is therefore making
unwise assumptions about its process state at invocation time.
Given that it usually runs as "root", this is a problem that sshd
can internally defend against:

  #if PAM
    curpri = getpriority (PRIO_PROCESS, 0);
    if (curpri > 0) {
      if (getuid () == 0) {
        put_a_warning_into_the_system_log ();
        setpriority (PRIO_PROCESS, 0, 0);
      else {
        put_a_different_warning_into_the_system_log ();

This code could be put into the startup path, or perhaps
be deferred to the initialization of forked sub-processes
as new connections get established.

Please consider this to be a bug this time!  If sshd doesn't
work correctly when invoked "nice'd", but has the power to
"un-nice" itself then is *should* do this.  This is nothing
more than (a) classic defensive programming, and (b) making
fewer assumptions and dependencies about the environment sshd
inherits.  Closing all file descriptors when invoked as a
daemon is precisely the same kind of elimination of assumptions
about the process environment being inherited!

Dave Warme
Comment 1 Tomas Mraz 2005-11-28 15:51:38 EST
Why do you think Fedora Core 1 is still supported?

Please upgrade to a current FC release - some of the problems (which you should
have reported separately anyway) are fixed there. Some of the problems (closing
file descriptors when daemonizing) should be discussed with upstream maintainers.

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