'WORKDIR /' in Dockerfile produces unusable image

[alco]

$ uname -a
Linux ubuntu 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04 LTS
Release:    14.04
Codename:   trusty

$ docker version
Client version: 1.0.1
Client API version: 1.12
Go version (client): go1.2.1
Git commit (client): 990021a
Server version: 1.0.1
Server API version: 1.12
Go version (server): go1.2.1
Git commit (server): 990021a

Use this Dockerfile:

FROM ubuntu:13.10

WORKDIR /

And try to run a container from it:

$ docker build -t testy testy
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:13.10
 ---> 195eb90b5349
Step 1 : WORKDIR /
 ---> Running in 14fd6f3df746
 ---> 8fe3e9d009bf
Removing intermediate container 14fd6f3df746
Successfully built 8fe3e9d009bf

$ docker run -it testy bash
2014/06/23 13:11:57 Error response from daemon: Cannot start container 7cccf56aa57be9aed022161343aa479c47fa4c9a79285b9c4a68a75d7bfe58f5: /var/lib/docker/aufs/mnt/7cccf56aa57be9aed022161343aa479c47fa4c9a79285b9c4a68a75d7bfe58f5 is not within /var/lib/docker/aufs/mnt/7cccf56aa57be9aed022161343aa479c47fa4c9a79285b9c4a68a75d7bfe58f5

[crosbymichael]

ping @tiborvass can you take a look at this one?

[alco]

The error probably hides in the build command. Yesterday, I was able to pull an image (built with 0.9) and run it on docker 1.0.1. After rebuilding the image with docker 1.0.1, I can no longer run it.

[marcelchastain]

I have an almost identical error message using a non-root WORKDIR. I suspect this might be a bug with using WORKDIR in general.

[marcelchastain]

I think the problem is with the replacement around 7a0e599#diff-6ce9e79ddb91a3f06352abe1f2c72ecbL142 , or one of the similar parts that replaces 'filepath.Join' with 'symlink.FollowSymlinkInScope' .

symlink.FollowSymlinkInScope tries to determine if an absolute file path is within some base path, see https://github.com/dotcloud/docker/blob/master/pkg/symlink/fs.go#L28

The problem is that it uses strings.HasPrefix(filepath.Dir(link), root), so it's actually shortening the path during the comparison.

In the OP's example the function would have been called like this:
symlink.FollowSymlinkInScope('/var/lib/docker/aufs/mnt/7cccf56aa57be9aed022161343aa479c47fa4c9a79285b9c4a68a75d7bfe58f5', '/var/lib/docker/aufs/mnt/7cccf56aa57be9aed022161343aa479c47fa4c9a79285b9c4a68a75d7bfe58f5')

Because of the filepath.Dir(), the eventual comparison would become:
strings.HasPrefix('/var/lib/docker/aufs/mnt/', '/var/lib/docker/aufs/mnt/7cccf56aa57be9aed022161343aa479c47fa4c9a79285b9c4a68a75d7bfe58f5')

...which of course would evaluate to false.

The drop-in replacement of filepath.Join with symlink.FollowSymlinkInScope is the problem, and the problem should arise only when trying to handle directories (but not files).

[marcelchastain]

Ping @vieux @tiborvass, any comments on this?

[tiborvass]

@marcelchastain I have a PR coming. It's a bug in FollowSymlinkInScope.