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:
1.
2.
3.
  
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 ();
      }
     }
  #endif

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