Allow java executable to bind to privileged ports

[tristan0x]

The logstash container is not allowed to bind on privileged ports.
Logstash provides some inputs whose default ports are in the privileged range. At least imap and syslog.

To reproduce

$ docker run --rm -ti logstash -e 'input { syslog { port => 514 } } output { stdout { } }'
syslog tcp listener died {:address=>"0.0.0.0:514", :exception=>#<Errno::EACCES: Permission denied - bind(2)>, :backtrace=>["org/jruby/ext/socket/RubyTCPServer.java:124:in `initialize'", "org/jruby/RubyIO.java:852:in `new'", "/opt/logstash/lib/logstash/inputs/syslog.rb:135:in `tcp_listener'", "/opt/logstash/lib/logstash/inputs/syslog.rb:90:in `run'"], :level=>:warn}

Use case

I want application containers to forward their logs to a syslog server (default port 514). In reality, the syslog server is a logstash container with a syslog input configured.

I use --link to bind application containers with logstash container so that application containers can use the LOGSTASH_PORT_514_TCP_ADDR environment variable to configure themself. Thus it requires logstash container to expose the 514 port.

[tristan0x]

mini-sample showcase with docker-compose available here:
https://github.com/cogniteev/docker-rsyslogstash/tree/779efe560f060be3f6f63968f5f26c5eab546c24/sample

[md5]

I wonder whether it would make sense to make this setcap change in the base java images.

There's some discussion about allowing non-root users in general to bind non-privileged ports in the container (started by @tianon, of course): moby/moby#8460

[md5]

I just read the latest comments on that issue and realized that it may not be possible to do in general.

[tianon]

It's my understanding that Docker does track these capabilities bits properly in the graph drivers, so this should be something we could set in the Dockerfile, and might indeed be something that's worth setting on java in general, especially since we're in a container and our port 80 is not the host's port 80 (except in the case of --net=host, which is already an extra level of trust thanks to breaking down part of the container walls).

[md5]

In my opinion, the notion of "privileged ports" is pretty outdated anyways.

[yosifkit]

@tristan0x, what do you think of #20?

[yosifkit]

(I totally missed/forgot that this was a PR 😮, and now that I look at your changes, I think that it might as well be baked into the image rather than just on run as long as the graph drivers handle it correctly 😄)

[tianon]

Turns out AUFS doesn't handle this correctly. 😢

Mind updating your PR to use "$(readlink -f "$(which java)")" instead of the hard-coded JDK 7 path?

[tianon]

Oh ouch, even that won't work:

$ docker run -it --rm logstash bash
root@0fb6599489df:/# setcap 'cap_net_bind_service=+ep' "$(readlink -f "$(which java)")"
Failed to set capabilities on file `/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

[justincormack]

This should work now on a more recent version of aufs.

[tristan0x]

Hi @tianon
Almost 1 year later, I have finally updated the PR according to your remark.

[mi-hol]

@tianon @yosifkit could you please comment on this regarding chance for getting merged?

[tianon]

@justincormack are you sure this is fixed in recent versions of AUFS?

FROM debian:jessie
RUN setcap 'cap_net_bind_service=+ep' "$(readlink -f "$(which bash)")"

I built the above Dockerfile, and it works successfully on OverlayFS, but on fairly recent AUFS (20161010), I get the following:

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM debian:jessie
 ---> 19134a8202e7
Step 2 : RUN setcap 'cap_net_bind_service=+ep' $(readlink -f $(which bash))
 ---> Running in 38cdeac8cd7e
Failed to set capabilities on file `/bin/bash' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
Removing intermediate container 38cdeac8cd7e
The command '/bin/sh -c setcap 'cap_net_bind_service=+ep' $(readlink -f $(which bash))' returned a non-zero code: 1

[justincormack]

@tianon yes, I don't know why I thought that then. overlay does succesfully roundtrip capabilities through hub, but aufs doesn't and I would not recommend using them.

[justincormack]

Unfortunately my other fix has been postponed, due to needing more changes in runc.

[tianon]

We're coming up on the 2 year anniversary of this PR -- I'm thinking maybe it's finally time to close it and wait for ambient capabilities to be implemented in Docker for handling privileged ports generically regardless of image? 😇 🙏 ❤️

[yosifkit]

Closing since this image is being deprecated.

This image is officially deprecated in favor of the logstash image provided by elastic.co which is available to pull via docker.elastic.co/logstash/logstash:[version] like 5.2.1. This image will receive no further updates after 2017-06-20 (June 20, 2017). Please adjust your usage accordingly.

Elastic provides open-source support for Logstash via the elastic/logstash GitHub repository and the Docker image via the elastic/logstash-docker GitHub repository, as well as community support via its forums.