[Olsr-dev] including wifi stats in jsoninfo
Hans-Christoph Steiner
(spam-protected)
Sat Jun 9 16:23:25 CEST 2012
On Jun 9, 2012, at 7:15 AM, Clemens Hopfer wrote:
> Hi,
>
> On Wednesday 06 June 2012 16:20:35 Hans-Christoph Steiner wrote:
>> [...]
>> I agree we should not put everything into olsrd. The stuff I'm talking
>> about is entirely in the jsoninfo plugin, so people don't need to use it
>> all. The jsoninfo plugin would not be larger than pud or tas with iwinfo
>> in it.
>
> keep in mind, that the plugin will be running with the same privileges as the
> olsrd, since it's just a loaded library. And since olsrd must be running as
> root, its a _very_bad_ idea to be able to call binaries from the plugin.
>
> Also, since olsrd is basically not threaded, it will block (pls correct me if
> I'm wrong) while processing data for the plugin communication.
>
> So being able to acces, and thus attack a olsrd plugin is directly attacking
> the olsrd itself, which is the core element of your infrastructure.
This is a weakness of olsrd for sure. Ideally, it would be structured so that only the parts that need root would have it, I think just the part that edits the routing table and to claim port 698. The rest would run as nobody or some very unprivileged user.
If you look at the jsoninfo plugin, its just reading olsrd internals, and reading files from the filesystem.
>> One idea for making olsrd smaller is making it easy to build the plugins
>> outside of olsrd itself, so they can be entirely separate projects. This
>> is a better approach IMHO than trying to limit what people do with
>> plugins.
>
> IMHO this should be an external application accessing the APIs of olsrd and
> the other binaries you want to get data from.
As far as I know, that's not currently possible since there isn't a public API. It would be nice to have a separate jsoninfo daemon that handled the network socket, reading data from olsrd, and whatever else.
.hc
More information about the Olsr-dev
mailing list