getcap/setcap ne fonctionne pas dans le conteneur docker avec Debian extensible hôte

Question

J'ai un hôte extensible Debian:

root@jenkins-docker-01:~# lsb_release -a 
No LSB modules are available. 
Distributor ID: Debian 
Description: Debian GNU/Linux 9.0 (stretch) 
Release: 9.0 
Codename: stretch 
root@jenkins-docker-01:~# uname -a 
Linux jenkins-docker-01 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64 GNU/Linux 

Et il fonctionne Docker:

root@jenkins-docker-01:~# docker version 
Client: 
Version:  17.05.0-ce 
API version: 1.29 
Go version: go1.7.5 
Git commit: 89658be 
Built:  Thu May 4 22:09:06 2017 
OS/Arch:  linux/amd64 

Server: 
Version:  17.05.0-ce 
API version: 1.29 (minimum version 1.12) 
Go version: go1.7.5 
Git commit: 89658be 
Built:  Thu May 4 22:09:06 2017 
OS/Arch:  linux/amd64 
Experimental: false 

Lorsque je tente de lancer un conteneur et utiliser getcap/setcap, il échoue avec pas pris en charge:

root@jenkins-docker-01:~# docker run --cap-add=ALL alpine /bin/sh -c "apk update && apk add strace libcap && getcap /bin/busybox" 
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz 
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz 
v3.5.2-80-g2df9a8dacb [http://dl-cdn.alpinelinux.org/alpine/v3.5/main] 
v3.5.2-78-gca9168c2cd [http://dl-cdn.alpinelinux.org/alpine/v3.5/community] 
OK: 7961 distinct packages available 
(1/2) Installing libcap (2.25-r1) 
(2/2) Installing strace (4.14-r0) 
Executing busybox-1.25.1-r0.trigger 
OK: 5 MiB in 13 packages 
Failed to get capabilities of file `/bin/busybox' (Not supported) 

Un strace montre que le problème est getxattr rendement EOPNOTSUPP:

execve("/usr/sbin/getcap", ["getcap", "/bin/busybox"], [/* 5 vars */]) = 0 
arch_prctl(ARCH_SET_FS, 0x7f419e716b48) = 0 
set_tid_address(0x7f419e716b80)   = 13 
open("/etc/ld-musl-x86_64.path", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/lib/libcap.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/usr/local/lib/libcap.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/usr/lib/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3 
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0 
fstat(3, {st_mode=S_IFREG|0644, st_size=18328, ...}) = 0 
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\23\0\0\0\0\0\0"..., 960) = 960 
mmap(NULL, 2117632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7f419e286000 
mmap(0x7f419e489000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x7f419e489000 
close(3)        = 0 
mprotect(0x7f419e489000, 4096, PROT_READ) = 0 
mprotect(0x7f419e713000, 4096, PROT_READ) = 0 
mprotect(0x56175c35e000, 4096, PROT_READ) = 0 
lstat("/bin/busybox", {st_mode=S_IFREG|0755, st_size=821408, ...}) = 0 
capget({_LINUX_CAPABILITY_VERSION_3, 0}, NULL) = 0 
getxattr("/bin/busybox", "security.capability", 0x7fff43487460, 20) = -1 EOPNOTSUPP (Not supported) 
writev(2, [{iov_base="Failed to get capabilities of fi"..., iov_len=66}, {iov_base=NULL, iov_len=0}], 2Failed to get capabilities of file `/bin/busybox' (Not supported) 
) = 66 
exit_group(0)       = ? 

Il y a beaucoup de références à ce problème sur Internet, mais tous suggèrent je besoin d'un noyau 4.0+, que j'ai. Des suggestions sur la façon de déboguer seraient appréciées.

et le débogage bonus info:

Containers: 22 
Running: 0 
Paused: 0 
Stopped: 22 
Images: 10 
Server Version: 17.05.0-ce 
Storage Driver: aufs 
Root Dir: /var/lib/docker/aufs 
Backing Filesystem: extfs 
Dirs: 93 
Dirperm1 Supported: true 
Logging Driver: json-file 
Cgroup Driver: cgroupfs 
Plugins: 
Volume: local 
Network: bridge host macvlan null overlay 
Swarm: active 
NodeID: 39ecfsepwam2v9vi47kc9ej4n 
Is Manager: true 
ClusterID: l4pokcim30kqofejjdvei8h4k 
Managers: 1 
Nodes: 1 
Orchestration: 
    Task History Retention Limit: 5 
Raft: 
    Snapshot Interval: 10000 
    Number of Old Snapshots to Retain: 0 
    Heartbeat Tick: 1 
    Election Tick: 3 
Dispatcher: 
    Heartbeat Period: 5 seconds 
CA Configuration: 
    Expiry Duration: 3 months 
Node Address: fe80::7210:6fff:fe52:b972 
Manager Addresses: 
    [fe80::7210:6fff:fe52:b972]:2377 
Runtimes: runc 
Default Runtime: runc 
Init Binary: docker-init 
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145 
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228 
init version: 949e6fa 
Security Options: 
seccomp 
    Profile: default 
Kernel Version: 4.9.0-3-amd64 
Operating System: Debian GNU/Linux 9 (stretch) 
OSType: linux 
Architecture: x86_64 
CPUs: 24 
Total Memory: 62.81GiB 
Name: jenkins-docker-01 
ID: UZ5O:MLAY:KDOH:TXZY:AICC:HNPA:TVOU:YDFV:ZE5D:EHMB:JARI:7IT5 
Docker Root Dir: /var/lib/docker 
Debug Mode (client): false 
Debug Mode (server): false 
Registry: https://index.docker.io/v1/ 
Labels: 
provider=generic 
Experimental: false 
Insecure Registries: 
127.0.0.0/8 
Live Restore Enabled: false 

WARNING: No swap limit support 

La sortie de modinfo aufs:

root@jenkins-docker-01:~# modinfo aufs 
filename:  /lib/modules/4.9.0-3-amd64/updates/dkms/aufs.ko 
alias:   fs-aufs 
version:  4.9-20161219 
description: aufs -- Advanced multi layered unification filesystem 
author:   Junjiro R. Okajima <aufs-users@lists.sourceforge.net> 
license:  GPL 
srcversion:  EAC7876AD444CD8E2C103D2 
depends: 
vermagic:  4.9.0-3-amd64 SMP mod_unload modversions 
parm:   debug:debug print (atomic_t) 
parm:   brs:use <sysfs>/fs/aufs/si_*/brN (int) 
parm:   allow_userns:allow unprivileged to mount under userns (bool) 

Answer 1

Je soupçonne que la version de aufs stretch ne supporte pas xattrs. Je ne peux pas trouver une citation récente, mais https://github.com/moby/moby/issues/1070 indique que c'était vrai en 2013.

Essayez le pilote graphique overlayfs, peut-être?

Answer 2

La réponse est que aufs de Debian Stretch est compilé avec CONFIG_AUFS_XATTR désactivé. Womp womp womp.

Edit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863166