[Olsr-dev] first sketch of jsoninfo olsrd plugin

[Hans-Christoph Steiner]

On 05/09/2012 03:39 PM, Henning Rogge wrote:
> On Wed, May 9, 2012 at 9:18 PM, Ferry Huberts <(spam-protected)> wrote:
>> On 09-05-12 20:43, Hans-Christoph Steiner wrote:
>>> On 05/09/2012 03:07 AM, Henning Rogge wrote:
>>>> On 05/09/2012 06:50 AM, Hans-Christoph Steiner wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>>
>>>>> I just pushed the first version of the jsoninfo plugin for getting the
>>>>> status and config info from olsrd in JSON format.  Right now, it gives
>>>>> all of the data that the txtinfo plugin does, indeed it is based on
>>>>> the txtinfo plugin.  It does not yet return the /config information.
>>>>
>>>> Very nice, I will have a look at it in the next days.
>>>>
>>>>> Also, I plan on adding the ability to configure HNAs at runtime via
>>>>> this plugin (like dyn_gw_plain).
>>
>> And how would this be secured?
>> I'm not feeling very comfortable with allowing random processes to change my
>> HNAs
> 
> Thats one of the advantages of two sockets... you can bind the
> "control" socket to 127.0.0.1... which at least makes it impossible
> for outside nodes to change your settings.

One simple but reasonably effective technique is to make a 127.0.0.1
socket that only allows one connection to it.  The Android app is
launching and managing olsrd, so it would be a tight timing attack for
another process to take control before the Android app does, then also
the Android app will notice that it can't connect, then kill olsrd and
try again.

Other approaches are possible, like using a UNIX sockets with file
permissions.

>>> One of the goals is to have a simple, standard-feeling API getting and
>>> setting things in olsrd.  Having the hna setting in a different plugin
>>> means opening a separate network socket, and would add needless
>>> complexity.  Instead someone who wants a standalone runtime_hna plugin
>>> could just take the code out of the jsoninfo plugin, and we have both
>>> options.
> 
> We will do this in the next release of OLSRd with the centralized
> telnet and http server. But I don't think mixing two totally different
> functionalities in the same plugin is really good.

I can't see the problem with a socket interface that allows you to get
the HNA settings and also set the HNA settings.  Is there something in
olsrd that would cause problems if the current jsoninfo plugin can also
receive commands to reset the HNA stuff?

.hc