What are the drawbacks for the open gateway workarounds with rootless Podman?

[StandingPadAnimations]

The docs for rootless Podman mention:

In rootless mode, podman resolves all incoming IPs as localhost, which results in an open gateway in the default configuration. There are two workarounds to fix this problem, both of which have their own drawbacks.

What I'm confused about is what are the drawbacks with either of the methods listed. Method 1 is setting PERMIT_DOCKER to none, but that seems to be the default:

docker-mailserver/mailserver.env

Line 71 in 726e2a5

PERMIT_DOCKER=none

The other involves network drivers, but beyond configuration, the docs don't mention any downsides of going down that route.

[polarathene]

Just a heads up, if these are quoting the v15.1 docs those were recently revised with a rather large update in quality and focus on Quadlet, but I was not able to complete the revision fully by verifying the newer pasta driver to earlier statements of rootless networking concerns which were specifically for the slip4netns driver.

So as mentioned in the link, some portions of those docs are potentially outdated until I or someone else can do another pass 😓

---

Method 1 is setting PERMIT_DOCKER to none, but that seems to be the default

Chances are that was also mentioned on the v15.0 and earlier version of the docs, where when that information was originally contributed the version of DMS at the time I don't think defaulted to none. Checking git blame on this ENV from our docs page on ENV settings, shows the PERMIT_DOCKER default change to none landed in DMS v11.0 (April 2022) and doing similar for the Podman docs page I see that PERMIT_DOCKER was added in this page for DMS v10.5 (March 2022).

---

The other involves network drivers, but beyond configuration, the docs don't mention any downsides of going down that route.

Unfortunately the quality of the docs will vary, especially for pages that don't follow our common "happy path" which has a larger demographic and more reports/testing such as the Docker engine with rootful containers instead of Podman / rootless containers.

As per the docs update link I provided, I was rather extensive on improving the Quadlet information contributed, but I would definitely encourage you to verify your setup with common flows you expect to have your DMS deployment perform.

So while I do try to keep our docs in shape, there's a possibility that our docs may not always be in the best state 😓

[StandingPadAnimations]

Just curious, would it be possible to use systemd socket activation with the container? From what I understand, sockets in rootless Podman preserve the source IP and avoid the performance penalty associated with pasta and slip4netns, which would address most of the rootless networking concerns in the docs.

The main downside of course is that the software inside has to support systemd sockets

[eriksjolund]

It's possible to have a daemon that uses socket activation for one port and PublishPort= for another port. Unfortunately, it will probably not work when using the container image docker-mailserver. It looks like docker-mailserver uses supervisord https://github.com/docker-mailserver/docker-mailserver/blob/5f4e868c541b142c705a643315ba8828d1836660/Dockerfile#L292C1-L292C62 This means that supervisord would inherit any socket-activated socket from its parent process. The question is if supervisord lets its child processes inherit such a socket. Probably not I would say. In any case, I think the proper solution would be to split up the container image docker-mailserver into multiple container images, one for each server. Supervisord would need to be removed. That is probably not easy and would be a lot of work. Each container image would run as a separate systemd service (defined in a container unit file). Maybe the containers should also run in a custom network. By letting dovecot run as a separate service, you can configure socket activation specifically for the dovecot service.

side note1: Maybe it's possible to run a dovecot container with Network=none to improve security. I wrote a blog post about the topic of using --network=none together with socket activation: https://www.redhat.com/en/blog/socket-activation-podman

side note2: docker-compose does not support socket activation of containers. To use socket activation with podman you would need to write quadlets (that is container unit files).