lib/40599: MKKERBEROS=no without MKPAM=no yields a broken system

[dholland%eecs.harvard.edu@localhost]

>Number:         40599
>Category:       lib
>Synopsis:       MKKERBEROS=no without MKPAM=no yields a broken system
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 10 02:45:00 +0000 2009
>Originator:     David A. Holland
>Release:        NetBSD 5.99.7 (20090209)
>Organization:
>Environment:
System: NetBSD tanaqui 5.99.7 NetBSD 5.99.7 (TANAQUI) #24: Mon Feb 9 11:19:51 
EST 2009 root@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386
Architecture: i386
Machine: i386
>Description:

Building a system with MKKERBEROS=no without also setting MKPAM=no
yields a completely broken system, in which all logins are rejected
because pam_krb5.so is missing. The only recourse appears to be to
cycle the power and recompile in single-user mode.

Furthermore, in this configuration xdm leaves xdm.core in /, which is
clearly not acceptable.

>How-To-Repeat:

build.sh

>Fix:

First, make things not fail miserably; that is, the pam libraries
should survive modules being missing without dumping core. This is
pretty basic.

Then, either the ritualized standard invocations in /etc/pam.d should
be installed without Kerberos when MKKERBEROS=no, or they should be
constructed robustly so that they will skip Kerberos if Kerberos is
not installed, without at the same time failing open under other
failure conditions. The second of these is obviously preferable, but
my (perhaps limited) understanding is that it is beyond the ability of
PAM.

I do not think it reasonable to expect the user to edit the muck in
/etc/pam.d to build a system without Kerberos; but in any event it is
certainly unreasonable to expect it when the need to do so is not, as
far as I can tell, documented.


The real (and more controversial) fix of course is to remove PAM and
replace it with something that works.