From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 22 10:41:01 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FF1B37B401; Tue, 22 Apr 2003 10:41:01 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE2D743FE3; Tue, 22 Apr 2003 10:40:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id DAA31713; Wed, 23 Apr 2003 03:40:54 +1000 Date: Wed, 23 Apr 2003 03:40:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Crist J. Clark" In-Reply-To: <200304161950.h3GJoYsJ007712@vegeta.cjclark.org> Message-ID: <20030423032101.O18429@gamplex.bde.org> References: <200304161950.h3GJoYsJ007712@vegeta.cjclark.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/51245: PAM will not allow users with null password tochange password X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:41:01 -0000 On Wed, 16 Apr 2003, Crist J. Clark wrote: > >How-To-Repeat: > As a non-privileged user, change your password to a null > (empty) password, > > $ passwd > Changing local password for user > Old Password: (old password) > New Password: (just hit ) > Retype New Password: (just hit ) > $ > > The user should now have an empty password. Try logging in with the > null password. It should work fine. But now try to change your > password, > > $ passwd > Changing local password for user > Old Password: (just hit ) > passwd: sorry > $ > > It will not let you. This works for me with -nearly-current userland, but I got an apparently- corrupt password database from having pwd.mkdb slightly out of date. After fixing this, everything worked right except for a bug in signal handling: hitting ^C at the prompts does nothing until I hit return. This is a standard bug for half-baked signal handling -- either signals are blocked, or signals are caught and do little except a set flag, and read() is restarted. getpass(3) works correctly, but passwd(1) apparently doesn't use it; something blocks SIGINT for the entire read().