On Wed, Oct 12, 2011 at 11:18 AM, Alan DeKok <[email protected]> wrote: > Evan Huus wrote: >> The problem is that pam_radius_auth (to the best of my knowledge) >> silently ignores any VSAs in the messages it receives. This makes >> sense from its perspective, since PAM is purely for authentication. > > Yes. And PAM can't change user authorization or permissions. So I > really have no idea why anyone uses PAM.
PAM does have a weak form of authorization management with the pam_setcred function [1]. I believe this is what the Kerberos PAM modules hook into to try and do what they need to do (I know even less about Kerberos than I do about RADIUS). On Wed, Oct 12, 2011 at 11:34 AM, Fajar A. Nugraha <[email protected]> wrote: > On Wed, Oct 12, 2011 at 10:02 PM, Evan Huus <[email protected]> wrote: >> The authentication part has been very simple thanks to the >> pam_radius_auth PAM module (I'm using the latest version: 1.3.17). >> Authorization has not been as simple. > > what permission is that? We have a system that is roughly analogous to Unix groups. Honestly if I were ever given the opportunity to write it myself I'd probably just implement it on top of Unix groups, but it's too late for that now. The current system was baked in long before I started working on the code-base. >> The best solution I've come up with has pam_radius_auth forwarding the >> Access-Accept messages to a configurable port on the local machine. >> Our daemon can then listen on that port and extract the data it needs. >> This solution is very ugly, and I'm hoping that there's a better way >> I'm just not aware of. >> >> Any suggestions or information you can provide are very much appreciated. > > If it's simple informations traditionally available on /etc/passwd and > such, you might have better luck hacking one of the available libnss-* > to create libnss-radius. This would be great if our authorization system was group-based, but it's not. I really like the idea though - I never would have thought of just writing it as an NSS service. --- My investigation into pam_setcred led into an investigation of how various Kerberos PAM modules are implemented, since they have to solve a roughly similar problem with Kerberos tickets. The cleanest example I've been able to find so far consists of writing the extra data to a file in /tmp/ and setting an environment variable with the path to the temporary file ([2], [3]). If I end up writing something similar into the pam_radius_auth code (which assumes that I can get management to sign off on modifying it given its GPL-ness), is that something that you guys would be willing to accept as a patch? Thanks for the feedback, Evan [1] http://linux.die.net/man/3/pam_setcred [2] http://www.eyrie.org/~eagle/software/pam-krb5/ [3] http://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html#S2 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
