Expansion of \t and \n in message with linelong module

[paul.moser at bt.com]

On Dec 24, 2014, at  13:20, Alan DeKok wrote:

>>
>> Very good point.  Because the set of attributes we happen to use in the log entry don't include end user inputted data and the source of those packets we are safe from unexpected expansion for now, but our future intended use and as a general use case this is certainly what's known as a bad >idea. Time to rethink.
>
>  It’s probably OK.  The main point is that untrusted data gets escaped.  Trusted data doesn’t.
>
>> It sound like we are doing much the same as Matthew Newton, in addition to performing some normal authentication/authorization/accounting we also send information from those to another radius server as accounting packet - in some cases this is for additional auditing, sometimes as it >enables other functionality - using the linelog module we could write out  a file in the standard detail format but with just the attributes we wanted (and the type as accounting even if it had originally been an access request), and use a detail listener to pick that up and send them on. Is there some >other way to do this that I've missed?
>
>  Nope.  I hadn’t thought of doing that, but it would work.
>
>  I’ll see if I can push a fix to the line log module.
>
>> I suspect the reason in our case that accounting packets are always used is just because historically it was more convenient to do so. Given we own the systems that the packets get sent onto it's possible that we may be able to change those systems to handle access request or response >packets as well as accounting, and modify the source systems to use a detail writer/read and Proxy-to-realm setup rather  line log
>
>  Accounting packets are probably the right choice here.
>
>  The longer term goal for the server is to extend the “originate-coa” functionality.  The server could receive an Access-Request, and just initiate an Accounting-Request, instead of going through a detail file.  Doing that requires some more architecture changes, which Arran and I will start in the >new year.

Have there been any further thoughts/changes on either expansion of escaped characters in the linelog or coa functionality? 

I can see from the git commit that's there's been some changes around these areas, especially around xlat but a cursory try of  both 3.0.7 and head from git suggest not, although I could easily be doing something wrong.

In the immediate future to allow me to  run on a recent FreeRadius version would I be better trying to proceed with getting a configuration running with correct_escapes = false?


Thanks,


Paul