Please look into the failed ci/circleci kubernetes-test. On the surface, the change appears to have rendered coredns unresponsive to dns queries, but could of course be some flaw or inadequacy with the test.

Please look into the failed ci/circleci kubernetes-test.

I don't have experience with k8s.

srv_test.go:52: Could not load corefile: timeout waiting for coredns to be ready. coredns log: Listen: listen tcp :53: bind: permission denied

I am familiar with the error though. I would say it's due to the non-root user binding below port 1024. This wouldn't normally be allowed on the host with CoreDNS would it? The binary isn't built/packaged with the capability enforced?

It is fine for Docker due to their internal bridge networks relaxing the port restriction.

My concern is from their comment in k8s by @vinayakankugoyal , where perhaps they relied on the container to bind to :53 internally for convenience and their network/runtime does not relax the privileged ports (which is what the capability would bypass).

It would seem that you can only keep one group happy 😅

• For DNS I can understand wanting to favor binding to :53 and needing that ability in other contexts beyond Dockers internal bridge networks.
• For those that bind to a > 1024 port internally and then publish that via :53, it's also warranted to not require NET_BIND_SERVICE capability in the image, since non-root user still works fine for that.

So I guess it's your choice as maintainer which one to favour. I don't have much input for k8s as I don't know how flexible that is with DNS configuration. Docker doesn't seem to allow changing the DNS port for containers with --dns for example. but is otherwise functional (like dig with -p which can choose the custom port to connect to).

This needs a DCO sign-off. You can use git commit -s --amend to add it.

This needs a DCO sign-off.

I'm aware, but in light of the k8s test failure I'll wait for maintainer decision on which route the Docker image should cater to.

If setcap is kept, I'll just raise a new PR (or adjust this one if preferred) to handle the WORKDIR and remove the ca-certificates.crt copy.

#5969 to support non-root feature. It seems largely unnecessary though?

Perhaps we should roll that back. Thoughts?

@polarathene I'm sorry for 'reviving' this PR after almost a year. Are you still interested in maintaining it and eventually merging it? As you and others have pointed out and as it has been referenced multiple times it's a bit cumbersome having to add the NET_BIND_SERVICE capability when running CoreDNS on non-privileged ports.

I tried retracing the discussions in #6249, #5969 and here. As I understand it, this change would be accepted and rolling back #5969 could also be done.

I'd be happy to see your change merged :)

Are you still interested in maintaining it and eventually merging it?

There's not much to maintain, as you can see from the diff it simplified it to just a COPY without any messing around with enforcing capabilities.

I'm presently at full capacity elsewhere and likely will be for a while. If someone else wants to pursue the change I welcome that, as it's been effectively stale for over a year since I attempted to push this forward. I'll otherwise eventually get back to this some time in 2025.

As you and others have pointed out and as it has been referenced multiple times it's a bit cumbersome having to add the NET_BIND_SERVICE capability when running CoreDNS on non-privileged ports.

The capability is always required for the functionality. The setcap approach grants it to the binary for a non-root user to have provided it's still within the bounding set (dropping all caps for the container would prevent that). This method is just a lazy way to go about enabling that for non-root.

The correct approach is for the devs to implement raising the capability when it's actually needed, otherwise failing. It should be roughly a few lines to implement that, I know how to do so with Rust but I'm not a Go dev, shouldn't be hard though.

It would then work regardless of in a container environment or not, no setcap enforcement needed (you'd still do this for non-root to be permitted to request the capability, just not to enforce it to run the binary). So you may want to do that for the container still, or those who want rootless could run the container as rootless (with a root user internally mapped to a non-root on the host).

AFAIK there isn't much concern about running as root if you drop the capabilities accordingly, the attacker would need some exploit to escape the container and that does not always require a root user within the container to do so. The capability required here isn't one that is needed for Docker IIRC, and I believe k8s also is making it redundant by setting the associated sysctl to 0 by default.

I tried retracing the discussions in #6249, #5969 and here. As I understand it, this change would be accepted and rolling back #5969 could also be done.

AFAIK the main benefit of running as non-root is the user does not need to think about extra precautions like dropping capabilities you don't need. I don't stay on top of CVEs related to this but to my knowledge the defaults (at least for Docker) are fairly reasonable and compromising the container should be quite difficult unless the user does something unwise, meanwhile those that want to take the additional precautions are likely to do so already rather than trust various upstreams do it correctly.

My experience with rootless is minimal, I've done so recently with Podman, but that seems a far better way to approach it for those that are more security conscious.

I'd be happy to see your change merged :)

Just to clarify, you don't seem to be marked as involved with the CoreDNS project directly?

The project maintainers still seem to be interested in the non-root approach they have in place?:

• Use a UID rather than "nonroot" in the Dockerfile #6416
• Planning next release 1.11.4 or 1.12.0 #6900

Just to clarify, you don't seem to be marked as involved with the CoreDNS project directly?

@polarathene Correct, I'm not directly involved with the CoreDNS project. Our project (gardener/gardener) consumes CoreDNS, and while not critically important, it'd be nice if we weren't forced to grant the NET_BIND_SERVICE capability when running CoreDNS on ports > 1024.

Thank you for your quick response and detailed explanation. I'll try contributing a change where the capability is raised dynamically when required 🤞

it'd be nice if we weren't forced to grant the NET_BIND_SERVICE capability when running CoreDNS on ports > 1024.

Oh ok. The only reason you wouldn't be forced is when the related systctl makes it irrelevant I think, otherwise you'd need to grant the capability (even for root if it were dropped IIRC).

If it helps, this is from an old comment of mine on the topic, demonstrating a non-root user with setcap only applying +p:

# Now with `+p`:
$ docker run --rm -it --user 1000 \
  --sysctl net.ipv4.ip_unprivileged_port_start=1024 \
  --cap-drop ALL --cap-add CAP_NET_BIND_SERVICE \
  cap-test-p inspect
Ambient: []
Inheritable: []
Effective: []
Permitted: ["CAP_NET_BIND_SERVICE"]
Bounding: ["CAP_NET_BIND_SERVICE"]

# Without the `--aware` flag this would fail
# since the cap would not be in the effective set:
$ docker run --rm -it --user 1000 \
  --sysctl net.ipv4.ip_unprivileged_port_start=1024 \
  --cap-drop ALL --cap-add CAP_NET_BIND_SERVICE \
  cap-test-p --aware

CAP_NET_BIND_SERVICE is required to bind a privileged port
CAP_NET_BIND_SERVICE is permitted but missing from the effective set
Successfully added CAP_NET_BIND_SERVICE into the Effective set
Successfully bound to: TcpListener { addr: 127.0.0.1:80, fd: 3 }

So if the desired port to bind is below net.ipv4.ip_unprivileged_port_start, you'll need to check that CAP_NET_BIND_SERVICE is in the permitted set (it should be by default for the root user, unless it was dropped from the bounding set). If it's permitted, then you can raise to effective set (allowing you to use that capability).

The above output is from a small rust program I wrote a while back to support justifying the change to not require it with CoreDNS, but I didn't get around to publishing it 😓

You can also test similar outside of Docker with systemd with ambient capabilities:

$ sudo systemd-run --system --uid 1000 \
  --unit cap-test-none \
  --collect --pty --quiet \
  --property AmbientCapabilities=CAP_NET_BIND_SERVICE \
  target/x86_64-unknown-linux-musl/release/capability-aware --aware

CAP_NET_BIND_SERVICE is required to bind a privileged port
The effective set already includes CAP_NET_BIND_SERVICE
Successfully bound to: TcpListener { addr: 127.0.0.1:80, fd: 3 }

# The `inspect` subcommand output (bounding set excluded):
Ambient: ["CAP_NET_BIND_SERVICE"]
Inheritable: ["CAP_NET_BIND_SERVICE"]
Permitted: ["CAP_NET_BIND_SERVICE"]
Effective: ["CAP_NET_BIND_SERVICE"]