Subject: lib/32447: default login class now mandatory despite login.conf(5) not specifying it
To: None <firstname.lastname@example.org, email@example.com,>
From: None <firstname.lastname@example.org>
Date: 01/03/2006 16:25:00
>Synopsis: default login class now mandatory despite login.conf(5) not specifying it
>Arrival-Date: Tue Jan 03 16:25:00 +0000 2006
>Originator: Matthew Mondor
>Release: NetBSD 3.0
NetBSD hal.xisop 3.0 NetBSD 3.0 (GENERIC) #0: Sat Dec 24 07:18:50 EST 2005 email@example.com:/usr/obj/sys/arch/i386/compile/GENERIC i386
I did a remote netbsd-2 to netbsd-3 branch upgrade from source on a
test box. Among some of the experienced problems (see install/32384),
it was impossible to login or to su anymore after the upgrade.
The cause is that a default login class is now mandatory in
/etc/login.conf and/or /etc/login.conf.db with the new pam_unix
module, if I understand. If no capabilities are present, there
is no problem.
The login.conf(5) man page doesn't specify this, and the postinstall(8)
script did not attempt to fix it or to warn about it.
In my opinion, the system should continue to function without,
or with a bogus, default login class. At worse, the login.conf(5)
manual page should be updated to stress that a default entry is now
mandatory, and the postinstall(8) script should at least cause a
test to fail against a proper default entry.
As it is now, even a typo in the default class entry will cause
(please post followups instead of trying to contact me personally
at this email address).
On a default install:
And curse when attempting to login again as root, needing to use
single user mode to correct the situation if no root shell still
A proper fix would in my opinion be to ignore a bogus or missing
default class entry in the capabilities database.
I would need to get more familiar with pam_unix.c and login_cap(3)
to quickly provide a diff. Probably that this can be fixed more easily
by someone with this background.