Authorization with Client PAM Library

Evan Huus eapache at gmail.com
Wed Oct 12 20:59:01 CEST 2011


On Wed, Oct 12, 2011 at 11:18 AM, Alan DeKok <aland at deployingradius.com> 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 <list at fajar.net> wrote:
> On Wed, Oct 12, 2011 at 10:02 PM, Evan Huus <eapache at gmail.com> 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



More information about the Freeradius-Users mailing list