Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

Salvatore Bonaccorso carnil at debian.org
Sun Nov 29 18:53:55 UTC 2015


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.

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.

Regards,
Salvatore



More information about the pkg-perl-maintainers mailing list