I use fedora silverblue and run syncthing inside of a podman container you get the following 2 warnings. It would be nice to be able to permanently disable them.
Syncthing should not run as a privileged or system user. Please consider using a normal user account
The Syncthing admin interface is configured to allow remote access without a password. This can easily give hackers access to read and change any files on your computer. Please set a GUI Authentication User and Password in the Settings dialog.
The first one is because podman maps the user starting the container to root inside the container and the second one is because synthing listen to 0.0.0.0 within the container but only 127.0.0.1 is mapped outside
It’s really a problem with the particular container’s configuration or the startup parameters.
Are you using the official container from the Syncthing project? Syncthing runs as user 1000:1000 and not 0:0 by default. There’s also an option to switch the GUI to 127.0.0.1:8384 (0.0.0.0:8384 is for ease of use with Docker).
For users who decide to run Syncthing as root in a container with Docker, a security warning is good because there’s a risk from a breach of the security sandbox that would result in root-level access to the host.
Thanks I’ll try the official image on the next host i setup, but as I mentioned in my previous message I run podman (rootless containers) not docker. So this is arguably safer than what you suggest (local root escalation within the container doesn’t translate to being root on the host after a breach from the container).
But anyway i was just asking about a way to hide those messages.
I also prefer Podman over Docker for similar reasons (Docker has a rootless mode, but it’s messy and comes with all kinds of caveats).
If Syncthing is running as root inside your container, how are you handling the file permissions on the host side?
Podman runs with the permissions of the user who started the container, but every file and directory your Syncthing container creates will try to set the ownership to root:root, which will be blocked – and that’s assuming the host directorie(s) already have the proper SELinux security context for the container to even touch any files to begin with.
(I haven’t spent much time using Fedora Silverblue. I primarily use Fedora Server, and am seriously considering Fedora CoreOS for a project at work.)
Not that I’m aware of within Syncthing’s settings.
I run Syncthing only under a non-root user with the web service bound only to the loopback interface, so the security warnings don’t appear. But even if it did, I don’t look at the web GUI very often (I use Syncthing-GTK on my desktop).
Since it’s just an immutable container, it should be simple to adjust the parameters, or worse case, switch to the official Syncthing container or Linuxserver.io’s Syncthing container (both of which support setting the UID and GID).
Unless you modify the code and compile your own Syncthing binary with the messages disabled, the only simple method to hide those would likely be to use a custom GUI theme which hides the messages using CSS. Alternatively, you could use browser extensions like Stylish or even UBlock Origin and hide the messages with them.
No, root user in podman should create files with the user’s uid/guid. But just found a new flag in podman that allows to reuse the user’s id (–userns keep-id:uid=1000,gid=1000). So that resolve the first warning.
I tried the official image now, but it still shows the listen address warning, and forcing to 127.0.0.1 with the ENV will break the UI. That feels like everyone running this container will have the warning shown.
You can set the advanced option GUI → Insecure Admin Access. That still gives you a one-time warning on startup that needs to be dismissed, but it’s slightly less aggressive about it. Alternatively, you can run with host networking which gains you working local discovery plus you can have the GUI listen on 127.0.0.1 which makes Syncthing happier.
It would still be helpful to have an advanced option so silence the " Syncthing should not run as a privileged or system user. Please consider using a normal user account." notice.
