Bug 27692

Summary: OpenSSH (all versions) doens't properly setup the PAM session handler.
Product: [Retired] Red Hat Linux Reporter: Uriah Welcome <precision>
Component: opensshAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: dr, pekkas
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-02-15 23:22:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Uriah Welcome 2001-02-15 02:04:25 UTC
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 22:58:06 UTC
See #25690 for a probably related issue and debug.


Comment 2 Uriah Welcome 2001-02-15 23:22:27 UTC
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 17:10:51 UTC
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 20:25:13 UTC
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