rlm_perl - Asymmetric attribute encoding

[Alan DeKok]

Scott Ireland wrote:
> In authorize, my script does an LDAP lookup and then sets the
> $RAD_CHECK{'Ldap-UserDn'} attribute for later:
> 
> rlm_perl: Added pair Ldap-UserDn = CN=Ireland\, Scott,OU=[...]

  That string is a Perl string.  It's allowed to have backslashes in it,
and they mean nothing special.

  The server treats backslashes as something special.

> In authenticate, I go to read this back but find that the \ in the
> attribute is coming back to me escaped:
> 
> rlm_perl: Added pair Ldap-UserDn = CN=Ireland\\, Scott,OU=[...]

  Yes.  The backslash is escaped.

> So, I end up having to strip off the escaping backslashes before using
> the value.

  Why are you escaping the comma?  That doesn't make much sense.  Commas
are allowed in strings in FreeRADIUS, and have no special meaning.

  The solution would be to *not* escape the comma in the first place.

>  I'm seeing something similar with the State attribute going
> out in an Access-Challenge and coming back in on the next
> Access-Request.  In authorize, I set $RAD_REPLY{'State'} to the single
> byte value 0x01 that I send back in an Access-Challenge  
> 
> rlm_perl: Added pair State = ?

  Because the State attribute is binary data.  The debug message is
trying to print that binary data, and not doing a good job of it.

> Sending Access-Challenge of id 253 to [ip] port 63308
>         State = 0x01
> 
> When authorize next sees the follow-up request from the NAS, things look
> OK in the RADIUS packet:
> 
> rad_recv: Access-Request packet from host [ip] port 14034, id=254,
> length=146
>        State = 0x01
> rlm_perl: Added pair State = 0x01
> But when I read it in Perl, $RAD_REQUEST{'State'} comes back as the
> string "0x01",

  That could be fixed.  But you could then argue that IP addresses
should be passed to Perl as a 4 byte binary blob.

  Well, the interface to the Perl code is text.  Always text.  If that's
difficult for Perl, that's just the way it is right now.

> so I have to turn around and pack() this to get back what
> I put in.
>
>  The same thing happens for different values as well; for
> instance, if I were to use the literal 1 as a value, State goes out as
> 0x31 (the string "1") and comes back in as the string "0x31", which
> again needs a pack() to fix.

  Sad to say, yes.

> I've been able to work around this by doing a bit of extra processing
> when I read any of these attributes back, but it doesn't really seem
> like intended behaviour.

  It's awkward, but it's consistent.  Everything is a string.

  For v3, it may be worth adding mapping functions like we now have in
LDAP and other places.  So you should be able to say "Yes, my Perl
script expects State as a binary blob.  That's fine".

  As always, patches are welcome.

  Alan DeKok.