[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pamifying a RADIUS daemon - help



On Fri, 18 Jul 1997, Savochkin Andrey Vladimirovich wrote:

> Thinking about using PAM I found that full authentication needs more
> than PAM specification allows. Namely, passing a lot of information
> (service, address, port and so on) from a PAM module (verifying password
> and extracting data from the same database) to the application. I would
> like to know your opinion about such problems. 

You can use the (void *appdata_ptr) pointer from the pam_conv struct
passed at the initialization time (pam_start call). Unfortunately, this
have some drawbacks: 
 - you have to do pam_start/pam_end for every auth or acct packet you
receive, mening that for every packet PAM lib will load/unload modules
from disk, lookup symbols, etc = overhead. This is because the PAM lib
saves the pam_conv struct when pam_start is called. One possible option is
to call pam_start when starting radiusd, then before each call to
pam_authenticate/pam_acct_mgmt/pam_open(close)_session you will have to:
	pam_setitem(pamh, PAM_USER, ...); /* modify the user name */
	pam_setitem(pamh, PAM_CONV, ...); /* supply the new AUTHREQ_HDR
					   * struct in appdata_ptr member 
					   */
But doing it this way you lose a lot of the 'pluggable' thing, meaning
that changing /etc/pam.d/radiusd configuration file will require a restart
of the radiusd server, to force the reload of the configuration file. If
the radiusd server is doing things like concurrent logins limit, it will
lose the internal data about currently logged in users, and in some cases
this is a critical loss;
 - you have to write specific modules which will make use of the
*appdata_ptr, something like (assuming you are familiarized with
current radiusd sources):

	struct pam_conv *my_conv;
	AUTHREQ_HDR *authreq;
	VALUE_PAIR *pair;

	pam_getitem(pamh, PAM_CONV, &my_conv);
	authreq = (AUTHREQ_HDR *)(my_conv->app_dataptr);
	pair = authreq->request;
	/* do your work */
 	
Yes, PAM is not very well suited to things like radiusd, but with little
imagination it can be done. This is how I am doing it here...

One possible start are the patches done by Jeff Blaize, altough those
aren't complete nor entirely correct (he have gone with pam_start/pam_end
thing for every packet, but he ommited the fact that he have to call
pam_end() - bug.). Also pam_open(close)_session thing it is not supported.
I have tryied to address these things somehow, I will make a patch
available for public discussion.

I have Cc:ed this reply to pam-list for constructive criticism :-)

Best wishes,
		Cristian Gafton
--
--------------------------------------------------------------------
Cristian Gafton                                    gafton@sorosis.ro
Computers & Communications Center              Network Administrator
http://sysadm.sorosis.ro/devel                         Iasi, Romania
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []