Docker-alpine: Proper way to open sub 1024 ports

[kilpatty]

I'm currently building a image that runs Caddyserver on Alpine-Linux. You can see my current setup/dockerfile here: https://github.com/ZZROTDesign/alpine-caddy

I'm looking for the "best practice" way to run this image from a non-root user. In the pre_install for caddy it creates a user named caddy, that code is listed on the alpine-linux apk registry.

If I try to run the image as User: caddy, then I get a permission denied for the inability to bind to port 80 and 443. What is the best way to open these ports up for a non-root user? Is adding caddy to sudo users the best practice in this case? Or is there some way to enable only caddy (the user) to be able to access port 80 and 443 and no other ports under 1024?
I've been searching all over, but the solutions I've seemed to find don't apply to alpine specifically as it does not have authbind.

Thanks for the help!

[andyshinn]

Is this unique to Alpine or Docker in general? The real issue seems to be https://github.com/docker/docker/issues/8460. I don't know that there is anything Alpine can do here.

[kilpatty]

Well it seems to be somewhat of a per OS or base-image problem as each image has different ways of managing users and permissions. Most solutions suggested setcap or authbind to allow particular users access to port 80 and 443, but neither of those are available on alpine, so I figured it was more of an Alpine question.

EDIT: on second read this does appear to be a pretty unsolvable issue as far as standards across all of docker. Just curious if anyone is aware of a "hacky-ish" way to solve this issue on Alpine. If not, we can close this.

[andyshinn]

Well, does it need to listen on a port < 1024 in the container? This is usually what port mapping is for (for example, map port 80 on the host to -> 1080 in the container).

[kilpatty]

Unfortunately yes, it seems that caddy needs to bind to ports 80 and 443 in order to verify for let's encrypt. I'm going to try to open an issue request to see if they can make that able to be changed, although it likely won't get rolled out into a release for awhile. Hopefully their is a short term solution that would be possible.

[thaJeztah]

Also see https://github.com/docker/docker/issues/8460

[justincormack]

setcap is in the libcap package in Alpine. Setting the filesystem capabilities is the recommended way of allowing this.

[gmile]

I'm running into a similar issue.

I'm trying to set up postgres DB in a Docker container, and hitting a roadblock during the final step, e.g. starting postgres process. I get this back:

/ $ postgres -D /pg_data
LOG:  could not bind IPv6 socket: Address not available
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create lock file "/run/postgresql/.s.PGSQL.5432.lock": No such file or directory
LOG:  database system is shut down

But 5432 is not privileged port, is it? Then why wouldn't alpine provide my user with port?

Update. Figured it out, somewhat. It was just that folder /run/postgresql/ was missing (also correct privileges must have been set).

[andyshinn]

That is more a support issue for running PostgreSQL and not really an issue with this base image. Please open a Stack Overflow question about it (including how you build and ran the container) and then ping me in our Slack and I can take a look.

I'm closing the original issue as well as it isn't really solvable in the base image. This is mostly normal for any Linux process that needs to listen on privileged ports with an unprivileged user.

Feel free to re-open if you think it warrants adding something to the docs or README about it.

[gmile]

@andyshinn thanks, noted on posting questions to SO.

It was only a few moments after I posted the question that I realized I knew the answer and it was completely unrelated to the initial issue described here (while at first I mistakingly believed my was related).