Hello, i want to use Silverblue and try not to overlay to much…
So to run Podman i let it generate (and modifid) this Unit File and run it with systemctl --user container-Syncthing.service, and so far it works.
# autogenerated by Podman 3.4.0
# Tue Dec 28 14:10:59 EST 2021
ExecStartPre=/bin/rm -f %t/%n.ctr-id
ExecStart=/usr/bin/podman run \
-p 8384:8384 \
-p 22000:22000/tcp \
-p 22000:22000/udp \
-v /var/home/jonas/.config/syncthing:/var/syncthing/config:Z \
-v /var/home/jonas/Bilder/Fotos:/var/syncthing/Fotos:Z \
-v /var/home/jonas/Dokumente/Paperwork:/var/syncthing/Paperwork:Z \
--userns keep-id \
--name Syncthing \
--label "io.containers.autoupdate=registry" \
ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id
The problem is without --network host there is no Local Discovery, and many of the Files are Big so i want that, but now i read you shoud not use network host because Security…
also is there any Securtiy risk by using --user keep-id?
So is there a better Way to do it?
PS: Currently i use the Unit File above and added the Local IPs of the other Devices manual…
I think you need to consider your risk model. If you are only running podman because you don’t want to install overlays or use a toolbox in silverblue and not because you are trying to fully isolate the contents of the container, do the risks associated with connecting the pod to your network more directly apply to you?
For me its mainly about spliting the things up, so applications and services are seperated from the System, the worst case for me would be to lower the security by this because higher attack surface with low seperation in between, i like the idea that is someone gets into the syncthing container, he can´t read anyfile thats not activly mounted to the container, and anything not mounted persistend just goes away by deleting the container.
So what worrys me is when i read there are bugs in other services that allow permissions escalation on the host if --network host is enabled
I never liked the idea of running things that are open to the outside on my System or as the PhotoPrism FAQ say:
Last but not least, virtually all file format parsers have vulnerabilities that just haven’t been discovered yet. This is a known risk that can affect you even if your computer is not directly connected to the Internet. Running apps in a container with limited host access is an easy way to improve security without compromising performance and usability.
My prefered way would be that podman tells Syncthings the outside IP and Syncthing would send that IP in its Multicasts and podman then relayes the Multicast… (I think Podman allready does that because i see the ip inside the container on the other devices to check if he gets a connect to it)
But for now the way in the PS works its just not really convenient…
It also works with Hostnames instead of IPs that for me solves the inconvieniens of looking up the IPs, and changing them in new networks.
Local discovery (multicast) will not typically work with any containers (Docker or Podman) without using
--net=host. I have been running Syncthing in a container on my laptop for years with host networking and have no trouble. If you use the global discovery service, devices on your network should be able to find each other without needing a relay service and without needing the local discovery. Syncthing has become pretty smart about finding finding devices!