On Jan 23,  3:23pm, Peter Seebach wrote:
} In message <200509030142.j831gFMB004060@vtn1.victoria.tc.ca>, John Nemeth writes:
} >On Jan 23,  3:12pm, Peter Seebach wrote:
} >}
} >} $ su
} >} su: pam_start failed
} >} 
} >} Well, that's awfully nice.  Such a detailed message!  And it makes it so easy
} >} to fix the problem, too!
} >
} >     Is there anything logged?  What are the permissions on su?  What
} >is in /etc/pam.d?
} >
} >     BTW, since this is a security issue, messages to users shouldn't
} >be overly detailed; the logs are where the details should be.
} 
} Yup.  Turns out that I didn't run all the postinstall stuff, and pam.d was
} empty.  *sigh*.  Better than it was last time.

     There have been a number of things over the years that can break
on an upgrade.  If you're going to run -current, then you really need
to pay attention to current-users for upgrade instructions.
postinstall has certainly made things much better, but you do have to
run it and pay attention to the output.

} I would prefer if the fallback for lack of PAM configuration were "just act
} like a traditional UNIX box".

     This would essentially require maintaining N different
authentication systems since on a "traditional UNIX box", every
application handled authentication itself.  This simply isn't going to
happen (not speaking for NetBSD, etc.).  This is one of the problems
that PAM is designed to fix.

     Besides, exactly what is the right thing to do when a security
subsystem fails?  Apparently, you would like the application to read
/etc/passwd.  Many would say that the system should fail closed.  What
happens if accounts aren't recorded in /etc/passwd?

     Question:  what would happen on a BSD Auth based system if the
Auth configuration files were missing?  Would it just guess at what to
do, or would it abort?

} And remember, an NFS filesystem mounted without nosuid can save your life.

     So can /rescue.

}-- End of excerpt from Peter Seebach