Date: Wed, 23 Apr 2003 03:40:53 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Crist J. Clark" <cjc@freebsd.org> Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/51245: PAM will not allow users with null password tochange password Message-ID: <20030423032101.O18429@gamplex.bde.org> In-Reply-To: <200304161950.h3GJoYsJ007712@vegeta.cjclark.org> References: <200304161950.h3GJoYsJ007712@vegeta.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <enter>) > Retype New Password: (just hit <enter>) > $ > > 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 <enter>) > 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().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030423032101.O18429>