Bug#879826: seccomp: missing sysinfo call
On Thu, Oct 26, 2017 at 02:28:05PM +0200, Bernhard Schmidt wrote:
> On 26.10.2017 13:50, Julian Andres Klode wrote:
>
> Hi Julian,
>
> >> Package: apt
> >> Version: 1.6~alpha2
> >> Severity: important
> >>
> >> sbuild/schroot in Debian stable, updating a sid chroot fails with a seccomp
> >> exception after apt has been upgraded to 1.6~alpha2 in the chroot
> >>
> >> root@BOTOX:~# sbuild-update -udar unstable
> >> unstable: Performing update.
> >> 0% [Working]
> >> **** Seccomp prevented execution of syscall 0000000099 on architecture amd64 ****
> >> Reading package lists... Done
> >> E: Method http has died unexpectedly!
> >> E: Sub-process http returned an error code (31)
> >> Exiting from update with status 100.
> >>
> >> Adding
> >>
> >> APT::Sandbox::Seccomp::Allow { "sysinfo" };
> >
> > I wonder: Why does it need that? Do you have any special libnss modules
> > installed? It seems odd.
>
> I'm not aware of anything, especially not in the schroot. It is a
> standard minimum chroot created using sbuild-createchroot. It's on a
> btrfs volume on a standard desktop that does not have any more special
> things I'm aware of. libnss-mymachines is installed on the host.
>
> > Could you run with APT::Sandbox::Seccomp::Print=false
> > and get a backtrace?
>
> Can you give me a pointer how? I'm not a regular gdb user, and the way I
> usually do it did not work
>
> unstable-amd64-sbuild)root@BOTOX:~# gdb /usr/bin/apt
> (gdb) set args update
> (gdb) run
> Starting program: /usr/bin/apt update
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Reading package lists... Done
> E: Method http has died unexpectedly!
> E: Sub-process http received signal 31.
> [Inferior 1 (process 28903) exited with code 0144]
> (gdb) bt
> No stack.
I don't think you can get it that way, it's one of the subprocesses
started. You could let it dump core (ulimit -c unlimited) and then
run gdb core /usr/lib/apt/methods/http I guess. I always just use
systemd-coredump which collects all cores automatically and then
all I have to do is run coredumpctl gdb, but I don't know if it
works in a chroot.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
Ubuntu Core Developer speaks English, German
Reply to: