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