In message <200509200107.j8K179K9024253@vtn1.victoria.tc.ca>, John Nemeth write
s:
>     Great, so you've covered things that can easily be handled through
>nsswitch (i.e. /etc/passwd, NIS, Hesiod).  What happens if
>/etc/nsswitch.conf is missing or a specified nsswitch module is
>missing?  What happens if there is some new scheme for encrypting
>passwords and the application doesn't handle it properly?  What happens
>if you are using Kerberos, S/Key, a smartcard, or something else that
>can't be handled by a simple getpwnam()?  How does the application
>decide when to fall back to its internal authentication handler and
>when to bail?  Why should the developers have to maintain N different
>authentication systems?  Are you volunteering to do this work?

My theory is that, since we already HAD functional code for doing the flat
file lookups, it would seem reasonable to, if we simply can't initialize
another system, try those as a fallback.

>     In other words, guess at what to do.  Not everybody would consider
>this the proper thing to do.

Well, yeah.

>} The comparatively simple configuration is sort of a plus.  :)

>     I don't find PAM configuration particularly difficult.

Simple as opposed to complicated.

How many files, one or many?  Is it a file in a standard format shared by
many other standard system files, or a custom file format?

>     If you have an ATX power supply and powerd is running, you can
>just poke the power button.  I understand the problem, but there are
>many things that can prevent a clean shutdown.  The problem with
>/rescue/rootshell is how to get it always do the right thing in a
>secure way.  At some point, you're just going to have type 'sync' and
>do it the hard way, and hope no filesystems are badly corrupted.

Uh-huh.

But in my case, the NFS filesystem saved the day.  :)

-s