containerd stripping filesystem capabilities

[kfox1111]

---

BUG REPORT INFORMATION

Description

We created an image using docker build, that contains a "USER daemon" line setting the default user.
This container functions properly in docker 1.13.

Under containerd xxxx running it:

ctr run testingimage:latest foo -t 
(ansible)[daemon@xxx1 /]$ ping google.com
ping: socket: Operation not permitted
(ansible)[daemon@xxx1 /]$ getcap /usr/bin/ping
(ansible)[daemon@xxx1 /]$ exit

it has its capabilities stripped off somehow. Doing the same under docker shows:

(ansible)[daemon@runner-2b155e38-project-255-concurrent-0ccvjk /]$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_admin,cap_net_raw+p
(ansible)[daemon@runner-2b155e38-project-255-concurrent-0ccvjk /]$ 

Output of containerd --version:

#containerd --version
containerd github.com/containerd/containerd v1.2.2 9754871865f7fe2f4e74d43e2fc7ccd237edcbce

capabilities running as the user on both show the same, correct result:

capsh --print
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,35,36+i
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,35,36
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=2(daemon)
gid=2(daemon)
groups=

[estesp]

Can you check the discussion in issue #2863 for any difference?

[kfox1111]

Hmm... yeah. that does look like it may be the issue. I pulled centos:centos7 and ran it and the capability isn't there. ping works as root, switching to daemon and ping fails. I checked the changelog and that patch hit after the 1.2.2 release happened so looks to be fixed in trunk. How far out is 1.2.3?

[kfox1111]

Is there any plans to do a 1.2.3 with the fix in it soon, or should I be looking at building from source?

[estesp]

#2974 is being used to prepare the 1.2.3 release for this week; a final bug is getting fixed and integrated and then the release should be ready to go.

[kfox1111]

Thanks for the heads up.

[fuweid]

Hi @kfox1111 , since containerd has released 1.2.4 which contains the fix, is it ok to close? thanks

[kfox1111]

I had previously upgraded to 1.2.4 but hadn't tried unprivileged pings until now. It does not seem to be working:
bash-4.2$ getcap /bin/ping
bash-4.2$
bash-4.2$ ping google.com
ping: socket: Operation not permitted

On the host, getting the version verifies it is the right version:
containerd github.com/containerd/containerd v1.2.4 e6b3f56

So, something is still wrong. Any ideas?

[kfox1111]

A thought occurs... The images are still probably cached on the node. Does the fix only apply to newer downloaded/extracted layers?

[fuweid]

Hi @kfox1111 , could you mind to remove the image and repull it again？if the image was pulled before, the containerd would not add the cap back. kfox1111 <notifications@github.com>于2019年3月2日 周六01:10写道：

…

I had previously upgraded to 1.2.4 but hadn't tried unprivileged pings until now. It does not seem to be working: bash-4.2$ getcap /bin/ping bash-4.2$ bash-4.2$ ping google.com ping: socket: Operation not permitted On the host, getting the version verifies it is the right version: containerd github.com/containerd/containerd v1.2.4 e6b3f56 <e6b3f56> So, something is still wrong. Any ideas? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2942 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQsyLZQTJ2yUi4rxkBVOQnXmv7GURr0Dks5vSV8dgaJpZM4aNbTh> .

[kfox1111]

Yeah. I'll test that.

[kfox1111]

Confirmed. Draining the node, removing all the images, then letting workload back on fixes the issue. Thanks!

[fuweid]

thanks! @kfox1111