Subject: Re: integrating PAM
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <>
List: current-users
Date: 01/21/2003 23:29:06
[ On Tuesday, January 21, 2003 at 18:32:58 (-0500), Dan Melomedman wrote: ]
> Subject: Re: integrating PAM
> Greg A. Woods wrote:
> > SASL:
> Seems huge to me. 

It's not small, but it's not really huge either.  It works and it works
well.  I use it for Cyrus IMAP.

> > BSD Auth:
> What does OpenBSD do about PAM?

Damned if I know for sure.  I'd bet they simply ignore PAM, though no
doubt the login_pam module for BSD/OS works just fine on OpenBSD too.

>  About NSS?

I don't think I've never heard of nsswitch called "NSS" until just now.  :-)

As you'll quickly learn by following the references in the above manual
page the user name lookups in OpenBSD are configured through login.conf.

On OpenBSD the host name services are still configured through the
"lookup" option in /etc/resolv.conf (as they were in NetBSD prior to
nsswitch being integrated):

                  bind  Use the Domain Name server by querying named(8).
                  file  Search for entries in /etc/hosts.
                  yp    Talk to the YP system if ypbind(8) is running.

It's all right there in their online manual pages.

It looks like OpenBSD's getnetent() and related routines are stuck in
the dark ages though with only "file" lookups supported. (perhaps
they've never heard of RFC 1101, now only a dozen years old...)

Personally I'd be more than happy if NetBSD's nsswitch was no longer
used for usernames and such and instead everything to do with usernames
was migrated to login.conf(5) leaving just host and network names
controlled by nsswitch.conf(5).  I really don't like tying user
identities together with host and network naming -- they are completely
and totally unrelated and should not be routed through the same lookup
mechanisms (even though sometimes the ultimate lookup protocols might be
used for both).

								Greg A. Woods

+1 416 218-0098;            <>;           <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>