Subject: Re: BSD auth for NetBSD
To: NetBSD Security Technical Discussion List <tech-security@NetBSD.ORG>
From: Todd Vierling <firstname.lastname@example.org>
Date: 09/12/2003 20:19:39
On Fri, 12 Sep 2003, Greg A. Woods wrote:
: > 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?
You have some research to do. We might as well end the discussion of the
internals here, and you can come back after reading the PAM client API.
: 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.
That's not the only thing PAM does. A "session" (i.e. login to logout) is
not the only encapsulating body for an authentication token.
You should note, Greg, that I personally don't like or use PAM, for similar
reasons to those you have mentioned. But certainly, given that it is
module-based, it wouldn't be unreasonable to desire NetBSD to have it as an
optionally loaded subsystem. "Don't use it if you don't want it."
Now, I have had occasion and necessity to use it in process control systems
at a semiconductor manufacturer. As a result, I do understand some of its
strong points, particularly how it's not just a "session" authentication
system. BSD Auth, however, *is* just a login session based authenticator.
In either case, the angle you're coming from is login session
authentication. This is something that need be neither of the BSD Auth nor
PAM APIs; that is why nsswitch exists. It's true that nsswitch as
implemented today isn't enough for either of BSD Auth or PAM, but it's the
perfect place to implement a way to get to either (...or the internal
-- Todd Vierling <email@example.com> <firstname.lastname@example.org>