Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Nov 2002 09:35:40 +0100 (CET)
From:      Volker Stolz <vs@foldr.org>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   bin/45669: pam_ssh fails in presence of SIGCHLD handlers
Message-ID:  <200211240835.gAO8ZeMs003709@monster.theater.foldr.org>

next in thread | raw e-mail | index | archive | help

>Number:         45669
>Category:       bin
>Synopsis:       pam_ssh fails in presence of SIGCHLD handlers
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Nov 24 00:40:03 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Volker Stolz
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
Lehrstuhl für Informatik II
>Environment:
System: FreeBSD monster.theater.foldr.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed Nov 13 19:42:10 CET 2002 root@monster.ikea.net:/usr/src/sys/i386/compile/MONSTER i386


	
>Description:
The pam_ssh module uses popen() to start an ssh-agent for the user during PAM
authentication. However, pclose() causes the pam-module to return an error if
somebody else already called waitpid(-1,...) because now pclose returns -1
and errno is set to ECHILD (observed with gdm who uses a whole bunch of processes).
>How-To-Repeat:
Install gdm, enable pam_ssh & try to login: You will get a login error an the first
try because the pam_module fails on pclose(). If you try for a second time, now
PAM will reuse the already running ssh-agent and let you in since it doesn't have
to take the popen/pclose path.
>Fix:
Either use signal(SIGCHLD,SIG_DFL) before invoking popen() (tested here, works)
or make the pclose() fail more gracefully when ECHILD is returned. For the latter
case, I'm not sure if this combination of -1/ECHILD can be caused by a real, 
fatal error.

Although the first solution is not bullet proof in cases where other processes are
repeatedly wait()ing, it least provides a viable workaround because as is the case
with gdm they do so in SIGCHLD handlers.

[When debugging/reproducing this, make sure you remove ~/.ssh/agent-* between runs!]
>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211240835.gAO8ZeMs003709>