unprivileged version

[atroost]

When using container on Kubernetes which is running in unprivileged mode port 80 can't be used.
This results in the following error:

Error: Could not get socket :80: Permission denied
(-? gives usage)

Would it be possible to create a image variant where the port is 8080 (>1024)?

A good example of that approach can be found here: https://github.com/nginxinc/docker-nginx-unprivileged

[gquintard]

Just tweak the entrypoint to set the work directory in /tmp and fix the port, and you should be fine:

varnishd \
	    -F \
	    -f /etc/varnish/default.vcl \
	    -a http=:8080,HTTP \
	    -a proxy=:8443,PROXY \
	    -p feature=+http2 \
	    -s malloc,$VARNISH_SIZE \
            -n /tmp/varnish_workdir

From there, you can run as an unpriviliged user. Just note that all the other varnish* tools will need to be called with the same -n argument.

I'm closing this as it's not a bug, please use the usual help channels if you wish to continue this discussion.

[atroost]

The things you mention I already and this indeed is not a bug. So no help is needed. I raised this issue as a feature request (and I don't see other options for that, other then update this repo with a pull request of my fork) From my point of view this would be a great addon for the official images on Dockerhub. If not... then I rest my case and continu using my own containers.

[gquintard]

my bad, I didn't realize that was an actual feature request . If you open a pull request, we would be happy to look at it. I would prefer though if we had a way to not make it a variant though and simply an option.
My worry is that we already have debian/alpine for three different versions.

The biggest issue I have is handling the work directory in a sane manner.

But, I feel I need to reiterate that you don't actually need a new image, just running a container like this:

# only override the http port, and the workdir
docker run -it --rm -u varnish varnish -a http=:8080,HTTP -n /tmp/varnish_workdir

is enough to run an unprivileged user.

I'm reopening this issue since it's indeed worth having that discussion.

[gquintard]

interestingly, port 80 doesn't seem to be privileged on the two base images we use, so we can actually just add

RUN chown varnish /var/lib/varnish
USER varnish

and things work. the only breakage would be for people using us in FROM and expecting to be root, but that's easy to spot, understand and fix I guess.

It seems like a decent solution to solve this feature request, I'll go with that and push a new image with the 7.0.1 release coming up next week. If you have remarks, opinions of want to share your current code, please pipe up before then.

[pcnoic]

interestingly, port 80 doesn't seem to be privileged on the two base images we use, so we can actually just add

RUN chown varnish /var/lib/varnish
USER varnish

and things work. the only breakage would be for people using us in FROM and expecting to be root, but that's easy to spot, understand and fix I guess.

It seems like a decent solution to solve this feature request, I'll go with that and push a new image with the 7.0.1 release coming up next week. If you have remarks, opinions of want to share your current code, please pipe up before then.

If I understand the release model correctly only bug & security fixes are to be backported into previous stable image tags as per https://github.com/varnish/docker-varnish/blob/v6.5/README.md?plain=1#L10 . Why did the unprivileged feature make it into 6.6.x? This commit is not tagged as a security fix hence the change IMO shouldn't have been backported, at least without notice.

[gquintard]

Hi,

So, there's currently no promise on the image stability, the documentation you point at describes the Varnish releases that are going to follow this pattern.

That being said, we don't enjoy breaking changes and now that we've had some experience in the docker space, it probably make sense to start making this promise

Originally, we started with the same template for all the versions so we could iterate faster, but we don't need that anymore, so I opened #45 to track this