[ On Friday, September 12, 2003 at 18:03:52 (-0400), Todd Vierling wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> That rather defeats the purpose of PAM.  Some authenticators (two-way smart
> cards are a common example) are *stateful* and cannot run outside the
> authenticated process without significant authenticator-specific context
> copy operations.

What stateful operations take place during (or at the end of) a session?
Exactly how much information do you suppose they might need to exchange
when such operations take place (i.e. what do you mean, more exactly, by
"significant")?  Do you have any concrete examples of such devices with
online documentation of their theory of operation that you could point
me at?

Sounds like a pretty broken design for something that's just supposed to
authenticate a user so that processes can be authorized to be run as the
UID that represents that user.  It makes no sense to even try to do
anything else stateful across the lifetime of a "session" within the
Unix security model, though doing something special at the end certainly
makes sense.  However we already have the potential for mechanisms
everywhere necessary such that an authenticator could be notified when a
session ends (though we don't yet have an API to make it runtime
configurable within the context of something like BSD Auth or PAM, but
neither do we yet have any configurable (nsswitch-like) API for
authenticators which could be used to front either BSD Auth or PAM).

So, if a two-way smartcard needs to know when a session ends then that
simply means we need an additional API callout for authentication
mechanisms that invoked at session end as well as the obvious one that's
need to initiate authentication.

If all that's needed is some way to kill a session when a smartcard is
disconnected then that can easily be done from the context of a separate
daemon process (which would be needed anyway unless one allows for a PAM
thingy to run a thread, but that would seem the ultimate of non-portable).

>  At that point, the whole point of running a pluggable
> *off-the-shelf* module in the same process context is defeated and you might
> as well not use PAM at all.

Indeed.  :-)

> All this babble is all FUD.  If you don't trust PAM modules, don't use them.
> But that doesn't mean others should be barred from using them.

Hmmm....  Why is it that you (and other folks) seem to keep assuming
that I am (or anyone else desiring BSD Auth first and foremost is)
trying to prevent others from using PAM?  I have never ever said that I
would refuse to allow anyoneto use PAM, and I've never ever tried to
even imply that others should never be able to use PAM with NetBSD
either.  I'm quite happy to leave people to make their own choices and
to allow that PAM might be one of the choices they should be able to
make with NetBSD.  I am of course trying to point out some of the
failings of PAM and I've been trying to show that it's not necessary for
any of things that people have been claiming so far that it's necessary
for.  If I can convince anyone that they'd be happier without PAM then
I'm probably going to try to do so.

All I desire of NetBSD, and I desire it strongly enough to be very vocal
about it, is some way to ensure that I can continue to very easily build
a PAM-free system from NetBSD sources and that I can continue to also
very easily build a static-linked system which still uses nsswitch too.
If I can continue to do those things and also have BSD Auth
ready-integrated into NetBSD then I'm twice as happy.  I myself don't
need BSD Auth for any custom authenticators since I'm quite capable of
integrating them directly with my own #ifdefs, but if BSD Auth is
available then I'll very happily use it instead, even if I still have to
write a custom authenticator program.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>