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

Alan DeKok aland at deployingradius.com
Wed Dec 24 14:20:39 CET 2014

On Dec 24, 2014, at 7:15 AM, <paul.moser at bt.com> <paul.moser at bt.com> 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.

  Alan DeKok.

More information about the Freeradius-Users mailing list