Hmmmm, see, right there, a need that pam_gss_authenticated() couldn't take care of as proposed... Gotta think some more about this :) Attribute-value pairs, with well established conventions seems to be a good approach, from a flexibility point of view. PAM environment variables will barely do though as their values can only be ascii strings. This is an argument for letting the app use pam_set_data(). I still think there's some advantages to having a pam_gss_authenticated(). Perhaps a pam_authenticated() with a variable argument list, with the arguments being av pairs. Hmmm... Later, Nico On Tue, Jan 25, 2000 at 10:23:18AM +0100, Max Liccardo wrote: > uau...good !! This is our problem....we use a cistron radius > autheticating users via PAM. The main problem is that it's hard (for > compatibily) to pass data others than pam-related variables, as the cli > or the client ip address(yes, radius has an user ip address, a NAS ip > addres and a proxy ip address!!!!) or the called number. solution 1) is > the simpest way, but an application should known exactly what a module > needs...I appreciate solution 2, as the free-radius does, i.e. he passes > the Av pairs to a loadable module trought a stack..., the concept: an > application should be able to share relevant data with the pam > framework...the PAM items seem to be useful for unix-like authentication > only. > max Content-Description: Scheda per Max Liccardo --
