Bug 174418

Summary: sshd denies non-root logins when running "nice'd"
Product: [Fedora] Fedora Reporter: David Warme <a039dmw>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: openssh-3.9p1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-28 15:51:38 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.