Subject: Re: BSD auth for NetBSD
To: Roland Dowdeswell <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 09/14/2003 13:46:15
[ On Saturday, September 13, 2003 at 20:15:55 (-0400), Roland Dowdeswell wrote: ]
> Subject: Re: BSD auth for NetBSD
> >> Two things: kerberos, s/key.
> > Adding either PAM or BSD Auth doesn't really make supporting either of
> > these in third party code all that much easier. Third party developers
> > still pretty much have to be prepared to use native OS support for these
> > two mechanisms regardless of whether they also support some more generic
> > framework such as PAM and/or BSD Auth.
> What?? This is incorrect.
If you had actually read any of the code for any major third-party
applications (e.g. those found in pkgsrc) you would have seen that I am
in fact 100% correct. You should go back and read that code before you
make further blatant mistakes like that.
> If you actually use PAM (and probably
> BSD Auth)
Fortunately portable third party applications _cannot_ assume that PAM
is available (just as they cannot assume BSD Auth is available). (And
yes, this is a very good thing since there's no POSIX API for making
authentication requests and checks.)
> Not for accepting passwords in cases such as xlock, xscreensaver,
> gdm, kdm, etc.
In fact if you look at those programs you'll find they many of them do
have direct support for each of crypt(), krb_verify_user(),
pam_authenticate(), auth_call(), etc. (see xdm/greeter/verify.c, for
example, which supports everything but S/Key directly it seems).
Even CVS (for its stupid pserver protocol), includes such direct support
of at least Kerberos, as well as of course crypt().
Like I say above: read some more code!
Even a grep for the obvious function names in the obvious places would
have verified what I said initially to have been correct.
> SASL is a different beast.
SASL as a protocol serves the same needs in a different environment.
However saslauthd does all of what I say above and will continue to do
so even if NetBSD joins either OpenBSD or FreeBSD in the "auth API wars".
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>