Thanks for reaching out.
Hi,
I have been trying to get podman to work with systemd.
I have a pod with 4 containers inside, along with the pause container, and I have generated systemd unit files using the command 'podman generate systemd --files'.
If I place the generated files into the /etc/systemd/user/ directory, then they run as expected, using the 'systemctl --user enable --now' command.
If I place them into the /etc/systemd/system directory they do not run. This is as I expected, since the files are all in the standard user's home directory, as are the volume mounts.
That's correct. By default, the unit files are bound to the current user. Generating the files with --new will create units that can be run by any user.
However, although I want them to run in the context of a standard user, I am concerned that if some hacker breaks out into my system then because the command to stop and start systemd unit user files will be available to them, then they can stop the running pod as a standard user, and my server and django site will be down. It's as simple as 'systemctl --user stop pod-xxx.service.
Doesn't that apply to any user on any system, including root? I would argue that running a server as a non-root user is more secure, especially when an attacker may get access to the host via that server; non-root can do less harm.
I discussed the issue briefly with velix on the irc podman chat, he suggested I use system groups. However, no matter how I configure my pod and container unit files, and whether or not I use 'loginctl enable-linger' I cannot get the pod to start.
I suspect that's because the unit files were not generated with --new. By default, the units will only start/stop the containers/pods which in turn are bound to a specific user. Using --new will create unit files that are more portable and can, in theory, be used by any user. The following blog goes into some details on that:
I have read that it is possible to start podman-containers having placed the unit files inside the /etc/systemd/system directory, which would mean that any command to stop the pod would be followed by the systemd bringing them back up, and the systemctl command to manipulate the pod wouldn't be available to the standard user.
Placing the files in the system directory makes them only accessible to the system services (requires root).
The man pages of podman-generate-systemd explain where and how to place the files for certain users.
So, what is the most secure way of starting the containers, in such a way, if possible, that should some influence gain unprivileged access, they cannot stop the pod.
I think that the most secure way is to run rootless, pretty much as you do now. If there is a legitimate concern that an untrusted entity can gain access to this machine, I would tackle that issue.
A major benefit of rootless containers is that in case an attacker manages to take over the container and gain access to the host, they will run as an unprivileged user; running a rootful container would imply acquiring root privileges which in turn means much more harm.
Kind regards,
Valentin
MTIA
James
--
James Stewart Miller Bsc(hons) Psych.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io