Bug#951577: Bubblewrap upstream-as-root test fails with libcap2 1:2.31-1 and later

2020-02-18 Thread Christian Kastner
Control: forwarded -1 https://github.com/containers/bubblewrap/issues/353

On 18.02.20 23:59, Christian Kastner wrote:
> I therefore believe that bubblewrap's test suite must be updated, so
> reassigning to bubblewrap.

FYI, I just checked GitHub (which I should have checked first...) and
there's already an issue opened for bubblewrap.



Bug#951577: Bubblewrap upstream-as-root test fails with libcap2 1:2.31-1 and later

2020-02-18 Thread Christian Kastner
Control: reassign -1 bubblewrap

On 18.02.20 11:49, Lukasz Zemczak wrote:
> Package: libcap2
> Version: 1:2.32-1
> 
> The bubblewrap upstream-as-root test started failing after libcap2
> 1:2.31-1 got synced from Debian. The same failure can be seen with
> 1:2.32-1. I have reproduced the issue locally on focal - when using
> the focal-proposed version, the aforementioned test fails, where with
> the release version (after reverting libcap2 to 1:2.27-1) it passes.
> 
> It seems to fail here already:
> bwrap --bind / / --tmpfs /tmp --as-pid-1 --cap-drop CAP_KILL
> --cap-drop CAP_FOWNER --unshare-pid capsh --print
> assert_not_file_has_content caps.test '^Current: =.*cap_kill'
> 
> It looks like the requested caps did not get dropped, as the logs show
> that both cap_kill and cap_fowner are still there. This is only for
> the upstream-as-root test, i.e. executing tests/test-run.sh as root.>
> This might be an issue with bubblewrap, but seeing that it all works
> fine with the release version, it all feels like an unintended
> regression.

I believe that this is just a side effect of how changes to how
libcap prints capabilities, probably caused by this commit [1].

I just tested this on a bullseye system with 2.27 (for brevity, I
replaced all other capabilities with "..."):

root@bullseye:~# capsh --print
Current: = cap_chown,...,cap_audit_read+ep
Bounding set =cap_chown,...,cap_audit_read

Compare this to a sid system with 2.32:

root@sid:~# capsh --print
Current: =ep
Bounding set =cap_chown,...,cap_audit_read

The difference is in agreement with the commit message of [1], and
according to the most recent cap_from_text(3), reads as "set all
capabilities in the effective (e) and inherited (p) sets".


Now note the output of your failed command:

> bwrap --bind / / --tmpfs /tmp --as-pid-1 --cap-drop CAP_KILL
> --cap-drop CAP_FOWNER --unshare-pid capsh --print
> assert_not_file_has_content caps.test '^Current: =.*cap_kill'

with 2.27,

Current: = cap_chown,xxx,cap_audit_read+eip

where xxx are all capabilities except the dropped CAP_KILL and CAP_FOWNER,

and with 2.32,

Current: =eip cap_fowner,cap_kill-eip

which, according to the most recent cap_from_text(3), reads as "start
with all capabilities, and remove cap_fowner,cap_kill".

So exactly what the test seems to attempt.

I therefore believe that bubblewrap's test suite must be updated, so
reassigning to bubblewrap.

[1] 
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=afef3ef1c62613e1cac12a2bbec6017f7d5e033e


Regards,
Christian



Bug#951577: Bubblewrap upstream-as-root test fails with libcap2 1:2.31-1 and later

2020-02-18 Thread Lukasz Zemczak
Package: libcap2
Version: 1:2.32-1

The bubblewrap upstream-as-root test started failing after libcap2
1:2.31-1 got synced from Debian. The same failure can be seen with
1:2.32-1. I have reproduced the issue locally on focal - when using
the focal-proposed version, the aforementioned test fails, where with
the release version (after reverting libcap2 to 1:2.27-1) it passes.

It seems to fail here already:
bwrap --bind / / --tmpfs /tmp --as-pid-1 --cap-drop CAP_KILL
--cap-drop CAP_FOWNER --unshare-pid capsh --print
assert_not_file_has_content caps.test '^Current: =.*cap_kill'

It looks like the requested caps did not get dropped, as the logs show
that both cap_kill and cap_fowner are still there. This is only for
the upstream-as-root test, i.e. executing tests/test-run.sh as root.

This might be an issue with bubblewrap, but seeing that it all works
fine with the release version, it all feels like an unintended
regression.

Reported on Ubuntu here:
https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/1863733

Best regards,

-- 
Ɓukasz 'sil2100' Zemczak
 Foundations Team
 lukasz.zemc...@canonical.com
 www.canonical.com