Subject: Re: BSD Authentication
To: Peter Seebach <seebs@plethora.net>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: current-users
Date: 09/05/2003 22:46:06
On Jan 17, 10:08pm, Peter Seebach wrote:
} In message <200308280827.h7S8Rbih024539@vtn1.victoria.tc.ca>, John Nemeth writes:
} >     The reasons I want PAM are twofold.  The first is because of the
} >ability to have "template users."  I did a "kiosk" project, which would
} >have been very difficult to do without it.
} 
} I don't know enough about the "template users" thing to know how hard
} it is to do; I do know that BSD/OS had a perfectly workable solution to
} the problem of handling many thousands of name/password combinations which
} ran in the same environment.

     In my case, xdm passed a username and password to a pam_radius
module.  This module then authenticated the username/password with a
RADIUS server.  If the username/password was authenticated, it told xdm
to use the "template user".  xdm then did getpwnam(<template user>) and
carried on as if it was actually the "template user" that was
authenticated.  login, ssh, etc. weren't allowed to use the pam_radius
module.  This way if somebody switched to a different screen, they
wouldn't be able to login.  The modules (an application may try more
then one authentication method/module) that each application uses are
specified in pam.conf.  Does BSD auth have a way of specifying
different modules for different apps?

} >     The second is that PAM is becoming ubiquitous.  Most OSes have it
} >now, i.e. Solaris, HP/UX, FreeBSD, Linux, etc., and most third party
} >apps that need to do authentication can use it.  There are also lots of
} >third party PAM modules.
} 
} Fine, so we eventually need to have it.

     Please, don't take what I wrote personally.  My comments weren't
really aimed at you.  I just used your note as a jumping off point to
express some of my thoughts on the issue.

} >One can also
} >argue about the design and/or security of it, but those arguments
} >aren't relevant when compared against the ubiquity of PAM.
} 
} By this argument, we ought to support Win32 executables natively, and provide

     I mentioned this, because certain people keep squawking about the
security of PAM as a reason not to include it.

     BTW, there is an ongoing project to support Win32 executables
natively.  Consider this line from GENERIC:

#options        COMPAT_PECOFF   # kernel support to run Win32 apps

I don't think the project is ready for prime time yet, but it is
coming.

} a system call for any program that wants setuid privs to be able to get them.

     This is just plain absurd.

} Ubiquity alone doesn't make a feature acceptable for NetBSD.

     Perhaps not, but it is a strong argument.  See:

http://www.netbsd.org/Goals/interop.html

}-- End of excerpt from Peter Seebach