"--disable-host-loopback" should be optional via an exposed AXParameter to enable remote connection from other acap applications

[fire-ant]

Describe the feature

I am advocating to add an AXParameter to enable access to the host loopback through toggling the presence of '--disable-host-loopback' in the rootless startup call here

My use case is consuming the cameras RTSP stream through a rootless dockerised application which may not be aware/detect underlying changes in the interface/IP configuration and should only need to know the relative path to the stream via 'host.docker.internal'.

I realise that RTSP also runs on a privileged port (554) but this can easily be remedied by enabling a custom port above 1024. If there are other services which cannot be moved to custom ports there might be consideration to allow for this but I do not feel that this issue scopes towards the implications of extendng to privileged ports.

Added value

There are a number of ACAP applications which will consume/forward data from the host for the purposes of recording/backup, telemetry and brokering communication via MQTT which is. natively configured and exposed on the host. Adding a method to explicitly allow loopback access to applications lets users make in an informed decision about whether they would like to implement a less secure (but not root privileged) feature in order to realise many of these applications.

There are many options/ways in which the problem can be solved outlined here but other solutions would require intermediary containers and combining sandboxes/functionality which feels brittle and difficult to implement for most initial users.

Im Happy to collaborate on the PR if the feature is welcome

[fire-ant]

@madelen-at-work @mattias-kindborg-at-work I hate to ping but this is time sensitive on my end and I'd like to proceed on the right path

[madelen-at-work]

Hi @fire-ant, Thank you for the suggestion. I think the fastest way forward is if you fork this repo and provide a PR for the change. Meanwhile we will investigate if this is desired functionality on our side.

[NickDarvey]

@fire-ant, did you end up forking to workaround this or find some other approach?

[fire-ant]

@NickDarvey Forked and managed to implement the workaround but wasn't satisfied with the overall approach. I've since moved the consuming application to a native ACAP (I learnt a thing or two in the process) which has proven the better option