Date: Fri, 22 Aug 1997 17:15:37 +0200 (MET DST) From: J Wunsch <j@ida.interface-business.de> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: ports/4356: sudo shouldn't block signals in tgetpass() Message-ID: <199708221515.RAA25020@ida.interface-business.de> Resent-Message-ID: <199708221520.IAA13540@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 4356 >Category: ports >Synopsis: sudo shouldn't block signals in tgetpass() >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ports >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 22 08:20:01 PDT 1997 >Last-Modified: >Originator: J Wunsch >Organization: interface business GmbH, Dresden >Release: FreeBSD 2.2-STABLE i386 >Environment: j@dasya 102% sudo -V CU Sudo version 1.5.3 >Description: sudo shouldn't block signals in tgetpass(), since this confuses the user typing ^C whether his wish to abort the operation has been recognized by the program at all. Signals should be caught, and handled appropriately. >How-To-Repeat: Type `sudo' with a sudoers file that requires you to type your password, and hit ^C. You need to type a newline in order to actually abort the operation. >Fix: This bug has been fixed in revs 1.3 and 1.4 of FreeBSD's libc version of getpass(3), back in 1995. It should be fixed in sudo in a similar way. (sudo's tgetpass() wants to expand %h and %u, thus libc's getpass(3) cannot be used directly.) >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708221515.RAA25020>