[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sheflug] AccessSpace NIS (lots of Q's)
>>>>> "Matthew" == Matthew Palmer <mjp16 [at] ieee.uow.edu.au> writes:
Matthew> PAM is a system for separating the function of
Matthew> authenticating users from the application. Rather than
Matthew> having to modify every program that needs to authenticate
Matthew> a user whenever you change auth mechanisms (say going to
Matthew> LDAP, or NIS, or Radius, or whatever) you can just make
Matthew> all programs call a PAM module, which takes the user's
Matthew> credentials (usually username and password) and then
Matthew> makes a decision about whether the user is OK or not, and
Matthew> tells the application. The application is told which
Matthew> module to use by a config file (in /etc/pam.d/<appname>
Matthew> usually) but knows nothing about what the module does to
Matthew> authenticate the user - it just knows that if the module
Matthew> returns 'yep, they're good' that they can let the user do
Matthew> whatever they were going to do.
Matthew> That's simplified, but it's all that's needed for now.
AFAIK, this explanation is somewhat more accurate than Alex's.
An analogy I like is the following. On DOS boxes, we used to do a lot
of direct console manipulation: read keystrokes, write to the screen
via the BIOS, etc. But on Unix, we just use the (pre-opened) stdio
streams. This has two advantages. One is that all programs can use
the best available implementation of console manipulation, because
it's in the standard library that every program links. The other is
that, with a little care in design, we can arrange to redirect I/O to
non-console streams: pipes, files, what have you.
Authentication on Unix boxes used to be similar. logind, ftpd, su,
etc used to have a lot of duplicated code to read /etc/passwd, read
authentication info from the user, do crypt operations, etc. And
often enough they'd be buggy. PAM is a common library of dynamically-
linked modules that can be linked into any program. This means that
everybody who worries about authentication services works on PAM, so
bug fixes automatically propagate to all PAM clients.
Second, we now know that passwords are a technically and socially weak
method of authentication. But because the PAM API presented to the
client is constant, PAM modules can implement various "back-end"
methods (both along the crypt dimension and along the database
dimension) of authentication, and these can be "plugged in" to any app
by changing a config file, just as you can redirect error messages to
a log with "prog 2>error.log". Thus improved methods can also be
propagated to all programs, just by updating PAM and changing config
files. (A la a more complex shell redirection, such as
"prog 2>| grep -v $BORING_WARNING_REGEX >error.log".)
Finally, you can decide on strictness of authentication by changing
which PAM modules you use, and their configuration, on a per
application basis (at least, maybe finer---I think it's actually
possible to cascade PAM modules so that a user who passes one check
will need to also pass another and that kind of thing). What standard
modules are available, I don't know, but there are already a lot.
One important difference between PAM and shell redirection is that PAM
redirection has to be two way (obvious if you think about it,
credentials go _to_ PAM, and "accept" or "refuse" is returned to the
client _from_ PAM).
HTH
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word
"unsubscribe" in the body of the message.
GNU the choice of a complete generation.