rlm_sql: %{sql:<long query>} - length limit

[Alan DeKok]

Kostas Kalevras wrote:
> The problem still stands that we cannot have xlat strings more than
> MAX_STRING_LEN. freeradius should impose a string length restriction on 
> the xlat output, not on the input. Maybe we could dynamically allocate 
> an input string if we see backquotes and store the xlated output in 
> VALUE_PAIR->data?

  Yes.  Ideally, the only part of the server that should know about
MAX_STRING_LEN is the packet encoding routines.

  That could be done via:

 a) new type PW_STRING_PTR (already defined)
 b) vp->data holding a pointer
 c) auditing the code for places that write to vp->vp_strvalue

  I've been thinking about related issues, such as why *ever* allocate
memory for strings in a VALUE_PAIR?  Why not just always use a pointer?
 For some types, it should be possible to point the string to the packet
data, which means no memcpy() (that's a non-negligible cost in the server).

  It may be easier to turn vp_strvalue && vp_octets into pointers.  That
will break all of the code, which will force an audit, to fix everything.

  Then, any code that writes to vp_strvalue or vp_octets would be
required to call a new function:

  pair_replace_string(VALUE_PAIR *vp,
                        const uint8_t *data, size_t datalen);

  That function would just do the right thing to get the new data into
the VALUE_PAIR.  It could start off in the current code with a simple
memcpy/strcpy.  Once all of the writes are updated to use this wrapper
function, then we could update it to swap the pointers.

  The main difficulty is the paircopy() routine, which makes copies of
the VALUE_PAIRs.  Would it malloc() room for the strings it copies, or
would it point to the data from the old string?  Maybe simply malloc'ing
it would be easier...

  This is one place where garbage collection would make the code MUCH
easier.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog