Bad permissions on a trusted container, but correct permissions locally

[florentx]

I've hit a bug where the Unix permissions are wrongly set when the image is built automatically (trusted build) but when I run the build locally (using the same Dockerfile) everything is fine.

How to reproduce:

$ docker --version
Docker version 0.11.1, build fb99f99
$ docker run -it tinyerp/sandbox-postgresql
root@4871d1b57a8e:/# service postgresql start
 * Starting PostgreSQL 9.3 database server                                                                                           [ OK ] 
root@4871d1b57a8e:/# sudo -u postgres createdb testdb
createdb: database creation failed: ERROR:  could not create directory "base/16385": Permission denied
root@4871d1b57a8e:/# ls -l /var/lib/postgresql/9.3/main/
total 64
-rw------- 1 postgres postgres    4 May 18 16:16 PG_VERSION
drwxr-xr-x 8 root     root     4096 May 18 16:20 base
drwx------ 2 postgres postgres 4096 May 18 16:20 global
drwx------ 2 postgres postgres 4096 May 18 16:20 pg_clog
drwxr-xr-x 6 root     root     4096 May 18 16:20 pg_multixact
drwx------ 2 postgres postgres 4096 May 18 16:20 pg_notify
drwx------ 2 postgres postgres 4096 May 18 16:16 pg_serial
drwx------ 2 postgres postgres 4096 May 18 16:16 pg_snapshots
drwx------ 2 postgres postgres 4096 May 18 16:20 pg_stat
drwx------ 2 postgres postgres 4096 May 18 16:26 pg_stat_tmp
drwx------ 2 postgres postgres 4096 May 18 16:20 pg_subtrans
drwx------ 2 postgres postgres 4096 May 18 16:16 pg_tblspc
drwx------ 2 postgres postgres 4096 May 18 16:16 pg_twophase
drwx------ 3 postgres postgres 4096 May 18 16:20 pg_xlog
-rw------- 1 postgres postgres  133 May 18 16:20 postmaster.opts
-rw------- 1 postgres postgres   98 May 18 16:20 postmaster.pid
root@4871d1b57a8e:/# 

The directories base and pg_multixact are wrongly owned by root when they should be owned by postgres.

This is the Dockerfile published (https://index.docker.io/u/tinyerp/sandbox-postgresql/):

# DOCKER-VERSION 0.11.1
FROM ubuntu:14.04

RUN mv /usr/bin/ischroot /usr/bin/chroot.orig \
 && ln -s /bin/true /usr/bin/ischroot \
 && export DEBIAN_FRONTEND=noninteractive LANG && apt-get update \
 && apt-get install -y --no-install-recommends language-pack-en \
 && update-locale LANG=en_US.UTF-8 && . /etc/default/locale \
 && apt-get install -y postgresql-9.3

RUN pg_ctlcluster 9.3 main start && pg_ctlcluster 9.3 main stop

CMD ["/bin/bash", "--login"]

The last RUN pg_ctlcluster instruction starts and stops the PostgreSQL server in order to create a DB user. (I removed the createuser -d openerp while troubleshooting the issue).

I'm puzzled why it builds without this error locally, but the image is built wrong on the public registry.

[florentx]

according to Docker support, it could be related to issue #4068 which is fixed in 0.10.
However the trusted builders run an outdated version of Docker.

The team plans two improvements:

• upgrade the trusted builders to the latest Docker version
• print the version of Docker used to create each trusted build

[florentx]

after 6 weeks and many exchanges with support@docker.com, I can only confirm that the issue still exists with 1.0 (on trusted builds only) : I've retried this morning

[unclejack]

@florentx I've pulled your image and it looks like this problem has been solved.

Can you confirm, please?

[didrocks]

I'm having the same issue on didrocks/docker-udtc. See the linked on github Dockerfile. I have no issue on a local build, but I can't even su - user (bad permission on /lib, /usr and multiple sub directories:

ls -l /

total 68
drwxr-xr-x 2 root root 4096 Jul 23 08:18 bin
drwxr-xr-x 2 root root 4096 Jul 23 08:16 boot
drwxr-xr-x 4 root root 4096 Jul 23 08:52 dev
drwxr-xr-x 197 root root 4096 Jul 23 08:52 etc
drwxr-xr-x 3 root root 4096 Jul 23 08:28 home
d--x--x--- 29 root root 4096 Jul 23 08:52 lib
drwxr-xr-x 2 root root 4096 Jul 17 03:34 lib64
drwxr-xr-x 2 root root 4096 Jul 17 03:34 media
drwxr-xr-x 2 root root 4096 Apr 10 22:12 mnt
drwxr-xr-x 2 root root 4096 Jul 17 03:34 opt
dr-xr-xr-x 327 root root 0 Jul 23 08:52 proc
drwx------ 2 root root 4096 Jul 17 03:38 root
drwxr-xr-x 12 root root 4096 Jul 23 08:26 run
drwxr-xr-x 2 root root 4096 Jul 23 08:18 sbin
drwxr-xr-x 2 root root 4096 Jul 17 03:34 srv
dr-xr-xr-x 13 root root 0 Jul 23 08:52 sys
drwxrwxrwt 2 root root 4096 Jul 23 08:26 tmp
d--x--x--- 35 root root 4096 Jul 23 08:52 usr
d--x--x--- 39 root root 4096 Jul 23 08:52 var

Dockerfile at: ubuntu/ubuntu-make@f7f7a4d

[nubs]

I believe I am also seeing this same issue. My Dockerfile creates a user using useradd and then switches to that user to install a few things in the home directory.

When I build the image locally, everything is /home/build is owned by the build user. The image pulled from the automated build, however, has incorrect permissions on the /home/build and /home/build/.composer directory, although the permissions are correct on the bash files that useradd created from /etc/skel.

[florentx]

@unclejack I've pulled the image, and I still see the same issue described in #5892 (comment)

[rvalyi]

Hello, amazing, I was testing an other Postgres image yesterday and ran into the exact same issue and Google brought me to #5892 so yes I think there is a Docker issue.

[arabold]

I also have a permission issue with automated build and docker, and wonder if this could be related or not.

I'm building a Go image based on Fedora:20 that works perfectly locally (Docker 1.1) but suddenly fails during automated build with a "Permission denied" error:

---> d3336af7fc3f 
Removing intermediate container 8e1511e200b3 
Step 13 : RUN /bin/go-build 
---> Running in 1c98a80d30a6 
�[91m/bin/sh: /bin/go-build: Permission denied
�[0m 
The command [/bin/sh -c /bin/go-build] returned a non-zero code: 126

Full Build Log

There's no manual change of ownership for any file or folder that I would know of (maybe during building Go itself).

[liftoff]

I am having this exact same problem now with liftoff/gateone image. Specifically, build bkuy8gznu3xbuq3gqmkiguk. When trying to run Gate One like so:

docker run -t --name=gateone -p 10443:8000 liftoff/gateone

...I get the following exception:

[E 140822 00:13:49 websocket:372] Uncaught exception in /ws
    Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/tornado/websocket.py", line 369, in _run_callback
        callback(*args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/gateone-1.2.0-py2.7.egg/gateone/core/server.py", line 1924, in on_message
        self.actions[key](value)
    File "/usr/local/lib/python2.7/dist-packages/gateone-1.2.0-py2.7.egg/gateone/core/server.py", line 2772, in get_theme
        for app in os.listdir(applications_dir):
    OSError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/gateone-1.2.0-py2.7.egg/gateone/applications'

I had a look inside the container using nsenter and can see the problem is with the directory permissions inside the gateone module:

root@9f08da6bbf22:/usr/local/lib/python2.7/dist-packages/gateone-1.2.0-py2.7.egg# ls -l
total 20
drwxr-xr-x  2 root root 4096 Aug 21 23:21 EGG-INFO
d--x--x--- 14 root root 4096 Aug 21 23:30 gateone
drwxr-xr-x  2 root root 4096 Aug 21 23:21 onoff
drwxr-xr-x  2 root root 4096 Aug 21 23:21 terminal
drwxr-xr-x  2 root root 4096 Aug 21 23:21 termio

That's the same permissions mask (d--x--x---) reported @didrocks (except in his case it was /usr and /var which is much worse). This problem does not occur when I build the Dockerfile manually.

[liftoff]

For reference, I tried setting umask 022 at the beginning of my RUN statement but that didn't do anything. The permissions problem starts at /usr and /lib and goes all the way through /etc, /usr and /var:

root@27076caf92b9:/# ls -l | grep d--x--x---
d--x--x--- 109 root root 4096 Aug 22 01:02 etc
d--x--x---   6 root root 4096 Aug 22 01:00 gateone
d--x--x---  27 root root 4096 Aug 22 01:00 usr
d--x--x---  24 root root 4096 Aug 22 00:59 var
root@27076caf92b9:/# ls -lR /usr | grep d--x--x---
d--x--x--- 44 root root 4096 Aug 22 01:00 lib
d--x--x--- 17 root root 4096 Aug 22 01:00 local
d--x--x---  4 root root    4096 Aug 22 00:59 gcc
d--x--x--- 5 root root 4096 Aug 22 00:59 x86_64-linux-gnu
d--x--x--- 7 root root 4096 Aug 22 01:00 lib
d--x--x--- 7 root root  4096 Aug 22 01:00 python2.7
d--x--x--- 20 root root  4096 Aug 22 01:00 dist-packages
d--x--x--- 8 root root  4096 Aug 22 01:00 gateone-1.2.0-py2.7.egg
d--x--x--- 14 root root 4096 Aug 22 01:00 gateone
d--x--x--- 5 root root 4096 Aug 22 01:00 applications
d--x--x---   5 root root  4096 Aug 22 00:59 apport
d--x--x---   4 root root  4096 Aug 22 00:59 bash-completion
d--x--x---   4 root root  4096 Aug 22 00:59 debhelper
d--x--x---  10 root root  4096 Aug 22 00:59 initramfs-tools
d--x--x---   5 root root  4096 Aug 22 00:59 lintian
d--x--x---   4 root root  4096 Aug 22 00:59 upstart
d--x--x--- 8 root root  4096 Aug 22 00:59 scripts
d--x--x--- 9 root root  4096 Aug 22 00:59 de
d--x--x--- 7 root root  4096 Aug 22 00:59 es
d--x--x--- 9 root root  4096 Aug 22 00:59 fr
d--x--x--- 7 root root  4096 Aug 22 00:59 it
d--x--x--- 7 root root  4096 Aug 22 00:59 ja
d--x--x--- 7 root root  4096 Aug 22 00:59 pl
d--x--x--- 6 root root  4096 Aug 22 00:59 pt_BR
d--x--x--- 7 root root  4096 Aug 22 00:59 sv
d--x--x--- 5 root root  4096 Aug 22 00:59 Debian
d--x--x--- 5 root root 4096 Aug 22 00:59 Debhelper

I'm tempted to just write a script that finds and fixes all these before Gate One starts but that seems like huge overkill for what is obviously a bug in Docker's build system.

[tanmaykm]

Ran into this problem with trusted builds (https://registry.hub.docker.com/u/tanmaykm/juliabox_dev/) and wasted a ton of effort trying to figure it out before I ran into this report.

My Dockerfile creates a user and switches to it before running further commands. The user's home directory ownership is incorrect and files created with some of the commands have incorrect ownership.

Added a chown to counter it, but that too is not reliable.

[liftoff]

Investigating this a bit, I was wondering why there aren't more folks running into this issue. It seems that it only impacts images that run their services as non-root. Sadly, almost all the public Dockerfiles and images run everything as root which is the opposite of security best-practices.

Considering the impact of that I believe this bug should be considered a major security problem. It doesn't bode well for the term, "trusted" that gets attached to these images.