Document Default Linux Capabilities the Docker Service Containers Are Assigned

[JacobSanford]

Greetings,

Has anyone had luck launching the 'official' mysql docker image with the new docker service? It appears to fail when the container tries to execute the ‘kill’ binary to restart after initial provisioning:

https://github.com/docker-library/mysql/blob/master/5.7/docker-entrypoint.sh#L87

.travis.yml:

sudo: required

language: ruby

services:
  - docker

before_install:
- docker pull mysql

script:
- docker run -e "MYSQL_ROOT_PASSWORD=123" --rm mysql

Output:

[...]
2015-09-04 14:45:39 62 [Note] Event Scheduler: Loaded 0 events
2015-09-04 14:45:39 62 [Note] mysqld: ready for connections.
Version: '5.6.26'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  MySQL Community Server (GPL)
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
2015-09-04 14:45:41 62 [Warning] 'proxies_priv' entry '@ root@2a6b869b59c1' ignored in --skip-name-resolve mode.

/entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
/entrypoint.sh: line 88: kill: (62) - Permission denied
MySQL init process failed.

full log
test repo
travis build

[JacobSanford]

Not a proper solution, but a new build with --privileged mode works:

https://travis-ci.org/JacobSanford/travis-docker-testing/builds/78839694

[BanzaiMan]

Am I correct to understand that this /entrypoint.sh script creates $DATADIR, runs mysqld as user mysql, and terminates it? How is this script expect to work without --privileged?

[JacobSanford]

@BanzaiMan I am admittedly terrible at writing bug reports. Thanks for the poke in the correct direction.

I would expect this because on a freshly installed local docker daemon, the default capability set does not restrict this. It appears that further capability restrictions are being put in place on Travis instances, and I have not seen documentation reflecting that.

Thanks!

[JacobSanford]

^^^ Perhaps a bit more targeted.

[BanzaiMan]

What capabilities do you expect to have documented?

[JacobSanford]

Hi @BanzaiMan,

The default security capabilities assigned to Docker containers that are launched via the new 'Docker Service' appear to differ from the defaults set by a standard Docker install on Ubuntu 14.04 Trusty Tahr (a blog post identifies Trusty as the daemon host OS).

Those differences in the default security capabilities did not allow the mysql image (which DOES run for me locally without --privileged or --cap-add in an docker 1.7.0 environment based on Trusty Server/Desktop) to run on Travis instances without specific capability escalation.

This was unexpected, and I couldn't find that outlined in any documentation. Knowing that may save time for others and avoid further issues. If you disagree, please do close the issue, as the concern has been resolved for me. Thanks for the great product.

Regards,

Jake

[joshk]

Hi Jake

Just as some extra information, could you try updating Docker to the latest version in your build?

eg.

before_install:
  - sudo apt-get update
  - sudo apt-get -y install lxc-docker

I would be curious to know if this helps at all.

Thanks

Josh

[JacobSanford]

Hi Josh,

No luck there with updating Docker. Additionally, upon further testing : including -cap-add ALL does not solve the problem, so it appears this isn't a security capability issue at all:

https://travis-ci.org/JacobSanford/travis-docker-testing/builds/78916544

which IMHO now indicates a restriction via access control (AppArmor?) or device restrictions on the host (since --privileged also extends those).

For now : hitting it with the --privileged sledgehammer does successfully deploy the mysql image into a container. That isn't a huge short-term concern for me, given that we're only using Travis for testing.

Thanks so much.

Jake

[JacobSanford]

I had some time to dig further this morning, and this issue does appear to be caused by related to AppArmor and is likely an emergence of:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1348698

From the build log:

Sep  6 14:48:59 testing-gce-902e49cd-f6cc-4970-b536-5e4d431311fd kernel: [   83.062714] audit: type=1400 audit(1441550939.877:9): apparmor="DENIED" operation="signal" profile="docker-default" pid=2578 comm="entrypoint.sh" requested_mask="send" denied_mask="send" signal=term peer="docker-default"
Sep  6 14:48:59 testing-gce-902e49cd-f6cc-4970-b536-5e4d431311fd kernel: [   83.062723] audit: type=1400 audit(1441550939.877:10): apparmor="DENIED" operation="signal" profile="docker-default" pid=2578 comm="entrypoint.sh" requested_mask="receive" denied_mask="receive" signal=term peer="docker-default"

Which IMHO shouldn't be seen as an endorsement for flushing AppArmor. To me, running containers as --privileged (for test environments) is still the lesser of the two 'evils'.

[joshk]

Thank you very much for helping find this @JacobSanford

I believe we disabled AppArmor, but I will need to get @meatballhat to help with this so we can figure out what is going wrong.

You rock!