Hi, On Sun, Nov 29, 2015 at 07:53:55PM +0100, Salvatore Bonaccorso wrote: > Hi Niko, hi Antonio > > On Sat, Nov 28, 2015 at 09:03:30PM +0200, Niko Tyni wrote: > > On Sat, Nov 28, 2015 at 07:22:01PM +0100, Salvatore Bonaccorso wrote: > > > > > > Package: liblinux-prctl-perl > > > > Version: 1.6.0-2 > > > > > > This package recently started failing its autopkgtest checks on > > > > ci.debian.net: > > > > > Thanks for reporting this. I can reproduce the test failures if I > > > build in a LXC container (running sid) on a sid host. > > > > > > As datapoint: Looks ci.d.n switched from schroot based test to LXC > > > based for at least liblinux-prctl-perl. > > > > Yeah, that makes sense. I expect the failures are just caused > > by different defaults and/or restrictions inside lxc containers.
Yes, it did. I have a pending announcement email to send about that and other things. > So indeed this seems the reason. First for the t/capbset.t failures. > The LXC configuration for the debian template contain: > > 12 # Default capabilities > 13 lxc.cap.drop = sys_module mac_admin mac_override sys_time > > and in same way for t/seccomp.t, this is caused by: > > 63 # Blacklist some syscalls which are not safe in privileged > 64 # containers > 65 lxc.seccomp = /usr/share/lxc/config/common.seccomp > > where in common.seccomp: > > 1 2 > > 2 blacklist > 3 reject_force_umount # comment this to allow umount -f; not recommended > 4 [all] > 5 kexec_load errno 1 > 6 open_by_handle_at errno 1 > 7 init_module errno 1 > 8 finit_module errno 1 > 9 delete_module errno 1 > > In this configuration, get_seccomp will return 2, > > # perl -E 'use Linux::Prctl qw(:constants :functions); say get_seccomp();' > 2 > > PR_GET_SECCOMP (since Linux 2.6.23) > Return (as the function result) the secure computing mode of the > calling thread. If the caller is not in secure computing mode, > this operation returns 0; if the caller is in strict secure com- > puting mode, then the prctl() call will cause a SIGKILL signal > to be sent to the process. If the caller is in filter mode, and > this system call is allowed by the seccomp filters, it returns > 2. This operation is available only if the kernel is configured > with CONFIG_SECCOMP enabled. I'm not sure how to proceed. Granted the lxc setup is way more secure than the previous schroot one, but we need to reach a compromise between being secure and being useful. Also, if some code is allowed to be executed on the buildds -- as I imagine this part of the test suite is -- it should also be allowed to run on CI. :) Do you have a recommendation on which lxc settings we might want to change for the CI test beds? Also note that at some point I want to add full virtualization with qemu+kvm, so if it's too difficult to figure out what needs to be changed maybe we can just declare this tests as needing full virtualization and they will be skipped for now. -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: PGP signature
