rlm_perl changing User-Name and proxy requests

[Arran Cudbard-Bell]

On 11 Jan 2013, at 20:49, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 01/11/2013 08:32 PM, Arran Cudbard-Bell wrote:
> 
>> Have you added nostrip for all the realms? The only way I can see it
>> clobbering username is if stripping is enabled.
> 
> Isn't the problem the special request->username attribute?

It is, request->username appears to be pointing to the original User-Name pair instead of the new perl one.

> AFAICT the pairmove code handles this specially ("fixup") but I'm not sure rlm_perl does the same?

Yes, unfortunately. That would have been a nice simple fix.

https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/modules/rlm_perl/rlm_perl.c

@leggett

If you don't mind rebuilding the server, could you change:

https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/main/modcall.c#L686

And add:

RDEBUG("Cached username is \"%s\", list username is \"%s\"", request->username->vp_strvalue, pairfind(request->packet->vps, PW_USER_NAME)->vp_strvalue);

Just after modcall_single()

Run it in debug mode and you'll see exactly where the username isn't being updated. List username and cached username should always be in sync up until the call to suffix, at which point the cached username should be stripped of the realm.


> 
> If that is the case, OP may find that putting the new username in an interim / temp variable then forcing update via unlang works:
> 
> authorize {
>  ...
>  myperl
>  update request {
>    User-Name := "%{The-Var}"
>  }
>  ...
> }

Yeah it should do. That calls radius_pairmove which has the magic update cache logic in it too.

-Arran