>So... Perhaps the right thing to do is treat this like other things which
>may *not* have interchangeable functionality.  If you use the BSD Auth
>scheme, and a PAM authenticator, some functions will be useless or always
>yield errors.  If you use the PAM scheme, and a BSD Auth authenticator, some
>functions may not work as expected.

Yep, and that's not so bad actually.

I was just going to say that it should be possible to support apps that
want PAM or BSD Auth, and still allow the admin to use what he wants.

Provided there is a pam_bsdauth.so, then apps that want PAM will be able
to use BSD Auth if that's what the admin wants - he just puts that as 
the only module in pam.conf

Similarly, provided there is a login_pam apps that want to use BSD Auth
will be able to use PAM if that's what the admin wants - he just has to
configure BSD Auth to only use that authenticator.

Now obviously login_pam won't be able to do everything things that PAM
supports, but the cool - frobb my context tricks typically require 
cooperation from the app anyway and clearly any app written for BSD Auth 
won't be making use of such features.

By the same token, if an admin wants to use BSD Auth he likely isn't 
planning on using those "cool" features.  

You can still have fully functional PAM and BSD Auth implementations
so everyone wins.

Now.... throw nsswitch.conf into the mix and it probably starts to
get ugly.  Though apps that use nsswitch.conf would likely fit 
better with the PAM model - since they are already doing shared 
objects?

--sjg