moby: docker build does not preserve xattrs in the generated image

Description Docker containers do not preserve extended attributes

Steps to reproduce the issue:

In the build phase, set an extended attribute on a file
Run the container and check for the existence of said attribute

I pushed a minimal image to the Docker Hub: mterron/xattrs The Dockerfile for it is inside the image at /Dockerfile so you can build it yourself and reproduce.

Describe the results you received: Build phase:

# attr -l /path/to/file
Attribute "pax.flags" has a 2 byte value for /path/to/file

Run phase

# attr -l /path/to/file
[empty response]

Describe the results you expected: When running an image I expect the xattrs to be the same as the ones set during build.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:      17.10.0-ce
 API version:  1.33
 Go version:   go1.9.2
 Git commit:   ba9946cf23
 Built:        Tue Nov 21 12:38:19 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.10.0-ce
 API version:  1.33 (minimum version 1.12)
 Go version:   go1.9.2
 Git commit:   v17.10.0-ce
 Built:        Tue Nov 21 12:37:42 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 4
 Running: 3
 Paused: 0
 Stopped: 1
Images: 47
Server Version: 17.10.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 0351df1c5a66838d0c392b4ac4cf9450de844e2d
init version: 949e6facb77383876aeff8a6944dde66b3089574
Kernel Version: 4.9.65-1-hardened
Operating System: Alpine Linux v3.7
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.732GiB
Name: nano
ID: 
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: 
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: true

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.): Physical environment

About this issue

Original URL
State: open
Created 7 years ago
Reactions: 2
Comments: 16 (8 by maintainers)

Commits related to this issue

Use whitelist for xattrs addresses https://github.com/moby/moby/issues/35699 Before this patch: DOCKER_BUILDKIT=0 docker build --no-cache -<<'EOF' FROM alpine RUN apk add --no-cache att... — committed to thaJeztah/docker by thaJeztah 5 years ago
Use whitelist for xattrs addresses https://github.com/moby/moby/issues/35699 Before this patch: DOCKER_BUILDKIT=0 docker build --no-cache -<<'EOF' FROM alpine RUN apk add --no-cache att... — committed to kstruczy/moby by thaJeztah 5 years ago
Use whitelist for xattrs Copy whitelisted extended attributes to the tar header. Before this patch, only security.capability xattrs were copied. After this patch, all xattrs from user.pax. and securi... — committed to kstruczy/moby by deleted user 4 years ago

Most upvoted comments

Looks like this works with BuildKit;

DOCKER_BUILDKIT=1 docker build -t repro-35699:buildkit --no-cache -<<'EOF'
FROM alpine
RUN apk -q --no-cache add nodejs attr \
 && attr -l /usr/bin/node
CMD attr -l /usr/bin/node
EOF


docker run --rm repro-35699:buildkit
Attribute "pax.flags" has a 2 byte value for /usr/bin/node

But still missing on the classic builder;

DOCKER_BUILDKIT=0 docker build -t repro-35699:classic --no-cache -<<'EOF'
FROM alpine
RUN apk -q --no-cache add nodejs attr \
 && attr -l /usr/bin/node
CMD attr -l /usr/bin/node
EOF


docker run --rm repro-35699:classic
# no output

I tried a very quick 'n dirty patch to address this https://github.com/moby/moby/compare/master...thaJeztah:support_xattrs, but it’s definitely not complete (currently assumes unix/linux, and not sure if the same path is called on Windows as well)

@tonistiigi @AkihiroSuda does BuildKit use a whitelist for these, or does it just copy all xattrs? (Should we have a whitelist?)

thaJeztah on Jan 30, 2019

I think we could support the whole of the security namespace, not just security.capabilities, and possible the trusted, security and system namespaces. user is the complicated one to support, as this is optional at file mount time, but the system special namespaces are always supported. It might make sense to do this in containerd now rather than here (or both; looks like much of the code is similar).

The pax namespace is a system namespace but not upstream in Linux, so it is a bit weird but I guess we could add it too.

justincormack on Dec 12, 2017

Historically, xattrs have been much desired but tap-danced around due to inconsistent support. We Red Hat even got support added to golang for this, but the filesystem support like aufs mentioned were troubling. Maybe this is different now. Xattrs ought to be on all Linux runtimes

On Tue, Dec 5, 2017, 11:56 Sebastiaan van Stijn notifications@github.com wrote:

I had a quick chat with @justincormack https://github.com/justincormack as well, and he had some more in-depth information regarding what groups of xattrs should be / could be included, and which not. I asked him to reply here as well but he’s currently at KubeCon, so there may be some delay 😅

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/moby/moby/issues/35699#issuecomment-349386123, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF6Y4QZq1AWWNFKwMtB84bUjx-zpSuks5s9YPHgaJpZM4Q1lWe .

vbatts on Dec 5, 2017

I had a quick chat with @justincormack as well, and he had some more in-depth information regarding what groups of xattrs should be / could be included, and which not. I asked him to reply here as well but he’s currently at KubeCon, so there may be some delay 😅

thaJeztah on Dec 5, 2017

@mterron I only digged for history on this topic; the discussion I linked to is over 4 years old; many things changed since, and most storage drivers (including recent aufs versions) now support extended attributes.

There may be more background, for which I reached out to two people that may have more information.

If there is no specific reason for not supporting, then it may just be something that was never implemented and can possibly be added.

thaJeztah on Dec 5, 2017