search

linuxserver / docker-unifi-network-application

GNU General Public License v3.0
551 stars 40 forks source link

[FEAT] Non-Root Runtime #90

Closed jbreed closed 1 month ago

jbreed commented 1 month ago

Is this a new feature request?

Wanted change

Ability to run without setting UID and GID and expect the user to be set externally.

Reason for change

Attempting to deploy this with mongodb in a helm chart. Mongo works just fine, but I get the following error when setting the security context for a specific UID and GID:

k logs -n unifi unifi-controller-app-66d45b6d8c-pbknr s6-overlay-suexec: warning: unable to gain root privileges (is the suid bit set?) s6-mkdir: warning: unable to mkdir /run/s6: Permission denied s6-mkdir: warning: unable to mkdir /run/service: Permission denied s6-overlay-suexec: fatal: child failed with exit code 111

I noticed in the docs the mention of --user for docker cli is not currently supported, which I imagine impacts this as well.

Proposed code change

I haven't looked yet at the entry script handling this, but a quick thought is whatever this code is for setting up the user can be wrapped in an IF statement to only run if an environment variable isn't set that informs the container that the UID and GID are already set so dont bother.

I will likely take a look at the entry script and see about mounting a modified version over it (assuming this is where its handled).

github-actions[bot] commented 1 month ago

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

jbreed commented 1 month ago

Quick look at the base image and appears a decent amount is taking place in the base, where the entrypoint is set to /init.

I just converted my old Unraid server into a Kubernetes machine to run other workloads and the idea was to migrate my old Unifi controller into Kubernetes while sticking with strict security policies. I will have to likely spend more time looking at how feasible it is to overwrite the entrypoint for this container, or look into building one.

I imagine I could take this Dockerfile component flow to pull the zip down, have the java dependencies loaded, then launch it (appears this may be 'java -jar ace.jar start')

Any ideas would be appreciated! Thanks

aptalca commented 1 month ago

https://docs.linuxserver.io/misc/support-policy/#unsupported-and-known-to-be-broken

jbreed commented 1 month ago

https://github.com/jbreed/unifi-controller

@aptalca - Just made a POC which appears to function after reading how this container launches.

I will deploy this via Helm and add the helm chart used to this repo once verified.

Not sure how open the team is to moving off the common base image.

Roxedus commented 1 month ago

We are not, it would not make sense to deviate from our base. There is already other images for this application that fit better for your usecase.

jbreed commented 4 weeks ago

https://github.com/jbreed/unifi-controller

@Roxedus Thanks. I ended up just making a revision as well as deploying the controller with a mongodb instance as part of a helm chart. I assume you guys do this to keep the image as lightweight as possible and not sure I want to try and remake the base. Given the notify Java class by UniFi requires systemd and some other packages, I ended up switching from Alpine to Ubuntu base and made my image a decent amount larger (about 2x the size of this image).

Maybe in the future I will dig into what you guys have going on in the base image to see if I can fork it. Thanks