NetBSD Problem Report #28505

From sjamaan@frohike.nvie.com  Wed Dec  1 23:10:07 2004
Return-Path: <sjamaan@frohike.nvie.com>
Received: from hermes.uci.kun.nl (hermes.uci.kun.nl [131.174.93.58])
	by narn.netbsd.org (Postfix) with ESMTP id DD4E3251EB9
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  1 Dec 2004 23:10:06 +0000 (UTC)
Message-Id: <20041201231146.895C86B335@frohike.nvie.com>
Date: Thu, 02 Dec 2004 00:11:46 +0100 (CET)
From: Peter.Bex@student.kun.nl
Reply-To: Peter.Bex@student.kun.nl
To: gnats-bugs@netbsd.org
Subject: getpass does not restore terminal after SIGCONT
X-Send-Pr-Version: 3.95

>Number:         28505
>Category:       lib
>Synopsis:       Sometimes getpass(3) echoes password chars after SIGSTOP + SIGCONT
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 01 23:12:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Tue Nov 20 13:50:09 +0000 2007
>Originator:     Peter Bex
>Release:        NetBSD 2.0_RC1
>Organization:

>Environment:


System: NetBSD frohike.nvie.com 2.0_RC1 NetBSD 2.0_RC1 (FROHIKE) #3: Wed Sep 29 19:34:49 CEST 2004 root@:/usr/src/sys/arch/i386/compile/FROHIKE i386
Architecture: i386
Machine: i386
>Description:
	When running su, suspending that by sending SIGSTOP and then resuming
	it again, in some shells (those that don't save/restore the child
	process' terminal state correctly) the password which is typed is
	echoed back to the terminal.

	This appears to be a bug in how getpass(3) handles signals.
>How-To-Repeat:
	$ /usr/pkg/bin/zsh
	% su
	Password:

	<switch to other terminal>

	$ pkill -SIGSTOP su

	<switch back to su terminal>

	Password:zsh: suspended (signal)  su
	% fg
	[1]  + continued  su
	<Password is now echoed to the terminal>

	I was only able to reproduce this problem under the zsh.
	(pkgsrc/shells/zsh, pkg version 4.2.1)
	/bin/csh and /bin/ksh don't have this problem (presumably because
	these shells save and restore child process terminal states)

	On a related note, /bin/sh does not do anything about the terminal,
	so when you start typing after sending the STOP signal to su,
	the characters aren't echoed.
>Fix:

Handle SIGSTOP and SIGCONT and set terminal state there.

--- getpass.c.orig	2003-08-07 18:42:50.000000000 +0200
+++ getpass.c	2004-12-01 22:34:21.000000000 +0100
@@ -52,6 +52,28 @@
 __weak_alias(getpass,_getpass)
 #endif

+/* Reset terminal on suspend/resume of the job, so pwd will not be echoed */
+static void sighan(int sig)
+{
+	struct termios term;
+	FILE *fp;
+
+	if ((fp = fopen(_PATH_TTY, "w+")) == NULL)
+		fp = stdin;
+
+	(void)tcgetattr(fileno(fp), &term);
+
+	if (sig == SIGCONT)
+		term.c_lflag &= ~ECHO;
+	else
+		term.c_lflag |= ECHO;
+
+	(void)tcsetattr(fileno(fp), TCSAFLUSH|TCSASOFT, &term);
+
+	if (fp != stdin)
+		(void)fclose(fp);
+}
+
 char *
 getpass(prompt)
 	const char *prompt;
@@ -63,6 +85,7 @@
 	int echo;
 	static char buf[_PASSWORD_LEN + 1];
 	sigset_t oset, nset;
+	struct sigaction act, ostop_act, ocont_act;

 	_DIAGASSERT(prompt != NULL);

@@ -84,6 +107,12 @@
 	sigaddset(&nset, SIGTSTP);
 	(void)sigprocmask(SIG_BLOCK, &nset, &oset);

+	sigemptyset(&act.sa_mask);
+	act.sa_handler = sighan;
+	act.sa_flags = 0;
+	sigaction(SIGSTOP, &act, &ostop_act);
+	sigaction(SIGCONT, &act, &ocont_act);
+
 	(void)tcgetattr(fileno(fp), &term);
 	if ((echo = (term.c_lflag & ECHO)) != 0) {
 		term.c_lflag &= ~ECHO;
@@ -101,6 +130,8 @@
 		term.c_lflag |= ECHO;
 		(void)tcsetattr(fileno(fp), TCSAFLUSH|TCSASOFT, &term);
 	}
+	sigaction(SIGSTOP, &ostop_act, NULL);
+	sigaction(SIGCONT, &ocont_act, NULL);
 	(void)sigprocmask(SIG_SETMASK, &oset, NULL);
 	if (fp != stdin)
 		(void)fclose(fp);

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: christos@netbsd.org
State-Changed-When: Wed, 01 Dec 2004 20:58:08 -0500
State-Changed-Why:
look at PR/10955


From: Peter Bex <Peter.Bex@xs4all.nl>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/28505
Date: Tue, 20 Nov 2007 09:24:03 +0100

 I was wondering if something was being done about this PR.  It's been in
 "feedback" state for a long time now, but that's the wrong state I think.

State-Changed-From-To: feedback->analyzed
State-Changed-By: tron@netbsd.org
State-Changed-When: Tue, 20 Nov 2007 13:50:09 +0000
State-Changed-Why:
The problem is well understood.


>Unformatted:

Home	PR Database Search