Linux getcap/setcap在具有Debian Stretch主机的docker容器中不工作

我有一个Debian Stretch主机：

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

它正在运行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

当我尝试运行容器并使用

getcap

/

setcap

时，它会失败，并且不支持：

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)   

strace

显示问题在于

getxattr

返回

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)                           = ?

在互联网上有很多关于这个问题的参考资料，但所有这些都表明我需要一个4.0+内核，我已经有了。关于如何调试的建议将不胜感激

和奖金调试信息：

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

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)

root@jenkins-docker-01:~#modinfo aufs
文件名：/lib/modules/4.9.0-3-amd64/updates/dkms/aufs.ko
别名：fs aufs
版本：4.9-20161219
描述：aufs——高级多层统一文件系统
作者：Junjiro R.Okajima
许可证：GPL
SRC版本：EAC7876AD444CD8E2C103D2
取决于：
vermagic:4.9.0-3-amd64 SMP模块卸载模块版本
parm:debug:debug打印（原子）
parm:brs:use/fs/aufs/si_*/brN（int）
parm:allow_userns:allow unprivileged在userns下装载（bool）

我怀疑stretch中的aufs版本不支持xattrs。我找不到最近的引文，但表明2013年的情况是如此

---

也许可以试试overlayfs图形驱动程序

答案是Debian Stretch的

aufs

在编译时禁用了

CONFIG\u aufs\u XATTR

。呜呜呜呜

---

编辑：

aufs，stretch中的版本肯定包含此代码。现在使用

overlay2

。。。但我不接受这个答案，因为@mithrandi说这应该行得通。问题在于AUF，所以答案是正确的。主帖子中添加的

modinfo aufs

@RicardoBranco的输出是什么。是的，代码在那里，但我没有注意到启用它的配置选项没有启用。哎呀。