Bug 27692 - OpenSSH (all versions) doens't properly setup the PAM session handler.
OpenSSH (all versions) doens't properly setup the PAM session handler.
Status: CLOSED DUPLICATE of bug 25690
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-14 21:04 EST by Uriah Welcome
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-15 18:22:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Uriah Welcome 2001-02-14 21:04:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-ac9 i686; Nav)


OpenSSH doens't properly setup the PAM session handle if you use it to
remotely excute commands (ie. ssh hostname /bin/bash)

Reproducible: Always
Steps to Reproduce:
1. Setup limits using the PAM limits module.  Add an entry to
/etc/security/limits.conf of '* soft nproc 50'.
2. ssh localhost, do a ulimit -a.. max user processes should be 50.
3. do a ssh localhost 'bash -c "ulimit -a"'
4. You will notice that max user processes doens't change from the default.

	

Actual Results:  step 2 showed a max user process of 50
step 3 showed a max user process of 256

Expected Results:  both should have displayed 50

This also works w/ _any_ PAM module that uses the 'session' handler.
Comment 1 Pekka Savola 2001-02-15 17:58:06 EST
See #25690 for a probably related issue and debug.
Comment 2 Uriah Welcome 2001-02-15 18:22:27 EST
Yep that's definately related.  What happens is that OpenSSH setups the PAM
session (when it does) before it drops all the permissions.. so what ends up
happening is it sees root as being limited to 20 processes and the user is
trying to create one more.. so you get  the fork() resource temporarily
unavailable.
Comment 3 Nalin Dahyabhai 2001-02-16 12:10:51 EST
Currently the build tree includes a patch which moves the open_session to after
the fork() and setuid().  It was committed to OpenSSH CVS, then modified to only
occur after the fork() (but before the setuid()) because some modules on
Solaris-derived implementations fail without root privileges.

This is exactly the problem I thought I'd solved under #25690.  Please check if
the pam-0.74-8 and openssh-2.3.0p1-16 packages for that bug ID solve this
problem.

*** This bug has been marked as a duplicate of 25690 ***
Comment 4 Uriah Welcome 2001-02-16 15:25:13 EST
Still doens't appear to be working..

[12:22:22] 505 [~]:harp% ssh localhost
precision@localhost's password:
[12:22:27] 501 [~]:harp% ulimit -a
core file size (blocks)     0
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
max locked memory (kbytes)  unlimited
max memory size (kbytes)    16384
open files                  1024
pipe size (512 bytes)       8
stack size (kbytes)         8192
cpu time (seconds)          unlimited
max user processes          50
virtual memory (kbytes)     unlimited
[12:22:29] 502 [~]:harp% logout
Connection to localhost closed.

[12:22:31] 506 [~]:harp% ssh localhost 'bash -c "ulimit -a"'
precision@localhost's password:
Warning: Remote host denied X11 forwarding.
stty: standard input: Invalid argument
core file size (blocks)     0
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
max locked memory (kbytes)  unlimited
max memory size (kbytes)    unlimited
open files                  1024
pipe size (512 bytes)       8
stack size (kbytes)         8192
cpu time (seconds)          unlimited
max user processes          8190
virtual memory (kbytes)     unlimited

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