enable rootless start #2

[kaktus42]

fixing pr #491 (issue #490) according to review comments

[bbernhard]

Thanks for the PR!

I quickly looked over the code and at first glance it looks really good. I'll have a more in-depth look at it in the next days, when I have a bit more time.

[poggenpower]

Hi created an image based on @kaktus42 patch-1 branch.
I am running signal-cli in a kubernetes cluster.

1. Test
   running still as root. It is working as expected on MODE=json-rpc

This is good no breaking changes!

2. Test
   Running as uid/gid 1000

+ set -e
+ [ -z /home/.local/share/signal-cli ]
+ [ -z 1000 ]
+ [ -z 1000 ]
+ RUNNING_AS_TARGET_USER=false
+ id -u
+ [ 1000 -eq 1000 ]
+ id -g
+ Already running as UID 1000 and GID 1000. Skipping privileged operations.
[ 1000 -eq 1000 ]
+ RUNNING_AS_TARGET_USER=true
+ [ true = true ]
+ echo Already running as UID 1000 and GID 1000. Skipping privileged operations.
+ [ json-rpc = json-rpc ]
+ /usr/bin/jsonrpc2-helper
time="2026-02-17T23:43:21Z" level=fatal msg="Couldn't create log folder /var/log/signal-cli-json-rpc-1: exit status 1"
stream closed EOF for signal-cli-rest-api/signal-cli-rest-api-6d79bc7d85-xtxdb (signal-cli-rest-api)

fixed /var/log/ by mounting supervisor and signal-cli-json-rpc-1 into an emptydir.
But would prefer to change the supervisor conf to send it to stdout as common vor containers:

[supervisord]
logfile=/var/log/supervisor/supervisord.log ;

stdout_logfile=/var/log/signal-cli-json-rpc-1/out.log
stderr_logfile=/var/log/signal-cli-json-rpc-1/err.log

next issue:

+ [ json-rpc = json-rpc ]
+ /usr/bin/jsonrpc2-helper
time="2026-02-17T23:56:59Z" level=info msg="Updated jsonrpc2.yml"
time="2026-02-17T23:56:59Z" level=fatal msg="Couldn't write /etc/supervisor/conf.d/signal-cli-json-rpc-1.conf: open /etc/supervisor/conf.d/signal-cli-json-rpc-1.conf: permission denied"

fixed /etc/supervisor/conf.d in same manner

next issue

+ [ -n -Xms612m -Xmx612m ]
/entrypoint.sh: 43: cannot create /etc/default/supervisor: Permission denied

Fixed this with an init container copying the file into an emptydir and remoted it with proper permissions.

next issue:

+ service supervisor start
Starting supervisor: Error: Cannot open an HTTP server: socket.error reported errno.EACCES (13)
For help, use /usr/bin/supervisord -h

another emptydir to /var/run fixes issues with permissions issues with the socket. Maybe moving it to the home dir would make it easier.

I really appreciate the efforts to create an non-root container. I know running in K8s is slightly different than docker, but I hope my test above will help. Happy to do more tests.

[kaktus42]

Thanks for running the tests!

As this goes a bit deeper as I thought, I'm not sure if I can find the time to make the necessary changes.
But good that your tests revealed already a couple of places to look at. Maybe someone else wants to pick this up.

[poggenpower]

@bbernhard I may want to spent some cycles on this, but want to discuss some directions first.
Instead of going with workarounds described above, I would like to design it root-less by default.
Therefor some questions:

• Do you see any reasons why user really need to run this container as root? Or is is more for "historic reasons"
• if running as User following things can be"optimized"
  • no cascading of service and supervisord
  • no requirement to drop privs for signal-cli-rest-api
• Are you open to switch to tini or s6-overlay? this may save 60-100MB image size.

[bbernhard]

@poggenpower Thanks for your tests - that's very much appreciated!

I am currently also having a look at running the image rootless, but unfortunately I am still fighting a bit with podman - for some reason building an image with podman is really slow. That makes the whole dev cycle a bit frustrating. (but might be because I am using a pretty old podman version; need to check that)

Do you see any reasons why user really need to run this container as root? Or is is more for "historic reasons"

I'd say it's more for historic reasons - at least I can't think of any reason right now that would require root. I am definitely open to improvements in that regard.

My checklist/"wishlist" would be:

• must not break any existing setups: newer setups can be root-less by default, but I'd have a better feeling if existing setups would be left as is - especially as there are some projects (e.g Signal Home Assistant Addon) which build functionality upon this project. And if something breaks, the tickets will most likely be created in this repository

• should be one image: Since this project is also used by users with less technical skills (e.g as notification service in Home Assistant), I'd like to avoid having multiple images to accomplish that goal. That just complicates things and will be harder to maintain.

• should be possible to connect into the container: For debugging purposes it's great to have the possibility to connect into the docker container and run signal-cli directly via a shell.

• "boring" technology preferred: I am a big fan of "boring" technology. So something, that has itself proven over the years and do not require a big tech stack with a lot of dependencies to work. But as far as I've seen, both tini and s6 seem to tick that checkbox.

• multi arch support would be great: since the image is built for x86-64, arm64 and armv7, it would be great to have a solution which works for all supported architectures.

• glibc vs musl: Years ago I did try to use base image which used musl instead of glibc, but ran into subtle issues on some architectures - so I switched back to glibc based base images. Not sure if that has changed, but just wanted to raise that as a potential issue.

[poggenpower]

Ok I will give it a try, it may need a while.

Maybe "boring" technology preferred and making it 100% backward compatible are conflicting heavily.
As the "boring" part means user 1000:1000 is the way to go. But this means if you start the container as before it is user space if you want to run it as root you need docker/podman/k8s tell to do it.

For debugging purposes it's great to have the possibility to connect into the docker container and run signal-cli directly via a shell. Should work as non-root even easier, no need for su - ... trick, you will enter it as the right user already. The opposite su - ... will fail, as su won't work anymore. As you can't get root anymore you won't be able to apt install ... further tools or do anything requires root e.g. doing a tcpdump .

So the new images will move to non-root as default and start as before user should only recognize if they do fancy things.

Are those changes acceptable from you prospective?

Maybe it is also an option to play out a non-root image in parallel for a while to collect some community feedback.

I can't really push to this PR, how should we proceed with it. Should we close this and I create a new one if I have a version. Should we move the discussion into an issue. Whats your preferred way there?