< email > home > pam

Some PAM modules

PAM is a clever way to separate out the `what' of user authentication from the `how' of an application trying to determine whether it's authorised. It allows, say, ftp to have its mechanism changed from vanilla /etc/passwd to /etc/shadow or Kerberos, retinal scan, or whatever else might be a good idea. All this without having to recompile ftp. Or pop, login, rsh, or any other Unix-based application.

It works though a central `server' library - libpam - which reads configuration files telling it how any given application should be authenticated. Those files can be changed (taking effect with the next authentication attempt) to reflect updated site policy.

Two modules written

(Written by me, anyway. Many more in the standard distribution from the PAM page.)

pam_tally/

This is a pretty simple module to count logins, optionally refusing login after a given number of failures. Root can be treated specially.

It comes in two parts: pam_tally.so is the pam module proper, pam_tally is the administrative program which interprets what pam_tally.so collects.

Oh, here's a third part: pam_tally_autoreset.pl which sits in a frequent cron (once a minute/five minutes) and resets anyone who's been blocked for a certain number of minutes. When I was using pam_tally myself, I just stuck a midnight cron in to delete /var/adm/faillog; autoreset is more elegant, I suppose.

pam_checkpassword/

This was written to allow the excellent qmail's pop system to run with RedHat's PAM-based authentication system. I haven't put up binaries of this yet.

This module comes in two parts too: the first (misnamed), checkpam should be compiled as a PAM application (get the pam distribution from here). This is the bit you tell qmail about - use it like the checkpasswd program.

The second bit is the PAM module, whose source is here, which goes with all the other PAM .so files, and should be inserted into /etc/pam.d/qmail-pop3d I believe it should preceed all other modules as auth required, because it cooperates with checkpam, but I've written to my former employer to find out. (This page is only a quick front end to things, I need to set up the pam stuff here sometime.)

Experimental: pam_virtual/

Experimental, as it says. This is a world-domination type thing.. I'd better explain. :)

My previous job was web admin, and I often had to set up a new virtual web host, with virtual email, and some virtual users (which is terribly easy with qmail), etc. This was easy enough, but involved editing about seven different files. So I wrote a script to handle that. So far so good.

NT, as I understand it, only needs something typed into a buffer, and a new server pops into life (after a suitably annoying reboot). I don't see why Linux (or Unix) should be any different, so I hatched this meta-config file, which can be told about several different virtual hosts, those hosts' virtual users, and which will then be able to rewrite the config files for things like named and httpd, then HUP them. Or maybe even someday just act as some sort of central database and unified config file for appropriate utilities which may then use a modified version of this system as an external way to read sections of their config files.

I'm sure there are better ways to do databasey things like this, but I wanted it text-editable, and fairly easy to write cgi-based admin tools. :)

Anyway, as I say, it's experimental, and at the moment, only the parse engine works. Comments are welcome though, and this is probably the most descriptive file.

< email > home > pam


This page last changed Tue Nov 11 09:26:30 2003