group.of.nepali.translators team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

FYI, >=16.10 has libseccomp >= 2.3. xenial has 2.2.3-3ubuntu3 that
includes updated syscall tables for this (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=809556 and
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1554098).

>=16.04 have 4.4 kernels and updated glibc.

** Bug watch added: Debian Bug tracker #809556
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809556

** Changed in: libseccomp (Ubuntu)
     Assignee: Jamie Strandboge (jdstrand) => (unassigned)

** Changed in: libseccomp (Ubuntu)
       Status: Confirmed => Fix Released

** Changed in: libseccomp (Ubuntu Xenial)
       Status: New => Fix Released

** Changed in: libseccomp (Ubuntu Trusty)
       Status: New => Triaged

** Changed in: glibc (Ubuntu Trusty)
       Status: New => Triaged

** Changed in: glibc (Ubuntu)
       Status: Confirmed => Fix Released

** Changed in: glibc (Ubuntu Xenial)
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1576066

Title:
  32bit glibc calls old socketcall() syscall, causing seccomp problems

Status in glibc package in Ubuntu:
  Fix Released
Status in libseccomp package in Ubuntu:
  Fix Released
Status in glibc source package in Trusty:
  Triaged
Status in libseccomp source package in Trusty:
  Triaged
Status in glibc source package in Xenial:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Released

Bug description:
  Back in the day when Linux was created for i386, for who knows what
  reason, all socket calls were multiplexed through a single syscall
  API, socketcall().  This was a strange thing to do, but it probably
  made sense from the standpoint of the same part of the kernel handling
  all of those calls.

  It was realised a long time ago that this was a strange and suboptimal
  arrangement.

  By the time they got around to doing amd64 and other architectures,
  they fixed this arrangement and gave each socket call a separate
  syscall entry point.  32bit systems continued to do it this old way,
  however, multiplexing all calls through socketcall().

  This is a problem for seccomp.  If we want to allow a program to make
  casual use of the network, but not bind a listener socket, we cannot
  currently do that.  On 64bits we just filter out the bind() and
  listen() calls, but on 32bit, it's all the same syscall.

  The kernel people fixed this problem up last summer by introducing
  new, separate, syscall entries for each separate call.

    http://patchwork.sourceware.org/patch/7679/

  The problem is that glibc in Y is still using the old socketcall()
  interface on i386.  It needs to be updated to use the new calls.

  A possible caveat is that this might create problems for running newer
  binaries on older kernels on i386 (as we sometimes do with builders)
  because they won't have the new syscalls.  A solution could involve
  checking for ENOSYS and trying again via the old route.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1576066/+subscriptions