Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fire-ant opened this issue May 5, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@fire-ant
Copy link

fire-ant commented May 5, 2024

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 fire-ant added the enhancement New feature or request label May 5, 2024
@fire-ant
Copy link
Author

fire-ant commented May 9, 2024

@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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants