[GH-ISSUE #84] Request: Run as unprivileged user by default (docker image) #55

New issue

Closed

opened 2026-03-15 12:19:01 +03:00 by kerem · 1 comment

kerem commented

2026-03-15 12:19:01 +03:00

Owner

Originally created by @LeoniePhiline on GitHub (Apr 3, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/84

Hi!

First of all, thank you for creating and sharing mailpit! ❤️

To increase runtime security, it would be great if the default dockerfile could run as an unprivileged user, instead of root.

See also good old MailHog's Dockerfile: https://github.com/mailhog/MailHog/blob/master/Dockerfile

What do you think?

Originally created by @LeoniePhiline on GitHub (Apr 3, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/84 Hi! First of all, thank you for creating and sharing mailpit! ❤️ To increase runtime security, it would be great if the default dockerfile could run as an unprivileged user, instead of `root`. See also good old MailHog's `Dockerfile`: https://github.com/mailhog/MailHog/blob/master/Dockerfile What do you think?

kerem closed this issue

2026-03-15 12:19:06 +03:00

kerem commented

2026-03-15 12:19:12 +03:00

Author

Owner

@axllent commented on GitHub (Apr 3, 2023):

Thanks for using Mailpit! I must admit that I considered this initially when I created the Docker image, but intentionally decided not to actually implement it. I found the disadvantages heavily outweighed the benefits of using a non-root alternative:

There is nothing stopping anyone from running their Docker container as any user they like (docs). Users savvy enough to specify a user in their Docker command would also understand the implications of permissions on any mounted volumes / directories.
I predicted that by setting a default non-root user I would get a constant stream of error reports when users were trying to use persistent storage, given that docker will create volumes and/or create mounted directories as root, requiring additional steps for anyone using these options to have to take additional steps to manually change their mount points' permissions, either on the host OS, or via docker itself (which isn't overly easy when the docker container is failing to start because Mailpit doesn't have read/write permissions to the storage volume / path).
Users wanting to run Mailpit in Docker using port 25 would hit issues as non-root users are blocked from running services below post 1024. I know they could simply map the ports via Docker, but there would always be some that would try.
In my opinion, running the Mailpit service as root within Docker is really not much of a security risk, if any at all, given that it is literally just Mailpit running within the container, Mailpit does not run any system commands, and it is running within Docker which separated it from the host OS. I cannot think of a single situation whereby Mailpit could be abused to "jailbreak" from Docker, or do anything it was never intended to. On that note too, Mailpit isn't a public-facing service, but a developer tool.
Switching now to running as a default non-root user will definitely cause upstream issues with anyone who has already provisioned environments with persistent storage, as existing mount points and database files will be root-owned. The only work-around for this would be to introduce some "init system" whereby the system is still started as root, and the startup scripts would chown/chmod the mounted volumes/directories to that of the "wanted user", however that introduces overhead and complications, not to mention the permission changes to the user's mount points. It also means that root is still being used, so how much is one "winning", if anything....

So my point is, I believe that switching to any non-root user by default is not a good option at all, and would not address any security concern I could imagine. As I mentioned in the first point, there is nothing stopping you from running it as any user ID or group you like, just by adding Docker arguments.

I hope my logic/reasoning makes sense to you?

@axllent commented on GitHub (Apr 3, 2023): Thanks for using Mailpit! I must admit that I considered this initially when I created the Docker image, but intentionally decided not to actually implement it. I found the disadvantages heavily outweighed the benefits of using a non-root alternative: 1. There is nothing stopping anyone from running their Docker container as any user they like ([docs](https://docs.docker.com/engine/reference/run/#user)). Users savvy enough to specify a user in their Docker command would also understand the implications of permissions on any mounted volumes / directories. 2. I predicted that by setting a default non-root user I would get a constant stream of error reports when users were trying to use persistent storage, given that docker will create volumes and/or create mounted directories as root, requiring additional steps for anyone using these options to have to take additional steps to manually change their mount points' permissions, either on the host OS, or via docker itself (which isn't overly easy when the docker container is failing to start because Mailpit doesn't have read/write permissions to the storage volume / path). 3. Users wanting to run Mailpit in Docker using port 25 would hit issues as non-root users are blocked from running services below post 1024. I know they could simply map the ports via Docker, but there would always be some that would try. 4. In my opinion, running the Mailpit service as root within Docker is really not much of a security risk, if any at all, given that it is literally just Mailpit running within the container, Mailpit does not run any system commands, and it is running within Docker which separated it from the host OS. I cannot think of a single situation whereby Mailpit could be abused to "jailbreak" from Docker, or do anything it was never intended to. On that note too, Mailpit isn't a public-facing service, but a developer tool. 5. Switching now to running as a default non-root user will definitely cause upstream issues with anyone who has already provisioned environments with persistent storage, as existing mount points and database files will be root-owned. The only work-around for this would be to introduce some "init system" whereby the system is still started as root, and the startup scripts would chown/chmod the mounted volumes/directories to that of the "wanted user", however that introduces overhead and complications, not to mention the permission changes to the user's mount points. It also means that root is still being used, so how much is one "winning", if anything.... So my point is, I believe that switching to any non-root user by default is not a good option at all, and would not address any security concern I could imagine. As I mentioned in the first point, there is nothing stopping you from running it as any user ID or group you like, just by adding Docker arguments. I hope my logic/reasoning makes sense to you?

kerem referenced this issue

2026-03-15 14:18:16 +03:00

[PR #55] [MERGED] Bump golang.org/x/image from 0.3.0 to 0.5.0 #422