Bug 354

Summary:	sshd with privsep doesn't do pam session setup properly
Product:	Portable OpenSSH	Reporter:	Rudolph Pereira <rudolph>
Component:	sshd	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED DUPLICATE
Severity:	normal
Priority:	P2
Version:	-current
Hardware:	ix86
OS:	Linux

Description Rudolph Pereira 2002-07-15 17:05:40 AEST

when logging in to an openssh >=3.4p1 sshd (I haven't tested earlier than that,
but I have tested up to the snapshot from the 14/7/2002) setrlimit, through the
pam session setup, isn't called in the appropriate place to allow specified
users to have higher ulimits than the server is started with. This ought to
work, as pam limits are allowed to specify arbitrarily high limits for users
listed. The problem appears to be that do_pam_session is being called after we
drop to the user's uid. Without privsep turned on, this all work, as we drop to
the user's uid after do_pam_session. Specifically: with privsep on,
do_setusercontext in privsep_postauth (sshd.c) is called before do_pam_session
in do_exec_pty (session.c). Without privsep, we only drop root privs in do_child
(session.c), which is after we do_exec_pty, since (obviously) the former
code/call to do_setusercontext is unreached.
A possible (does appear to work, though not properly tested) solution is to
simply call do_pam_session in privsep_postauth before the do_setusercontext
call, though I am unsure of the ramifications of this.

Comment 1 Colin Watson 2003-01-03 02:42:45 AEDT

Alternatively, perhaps sshd could be configured to setrlimit() everything up to
RLIM_INFINITY after forking but before giving up root privileges. It could then
rely on pam_limits to set limits back down if the administrator wants that,
which would work even with session modules run as non-root.

Comment 2 Damien Miller 2003-01-07 18:31:21 AEDT


*** This bug has been marked as a duplicate of 83 ***

Comment 3 Damien Miller 2004-04-14 12:24:18 AEST

Mass change of RESOLVED bugs to CLOSED