[Bug 1576066] Re: 32bit glibc calls old socketcall() syscall, causing seccomp problems

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1576066

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

Status in glibc package in Ubuntu:
  Confirmed
Status in libseccomp package in Ubuntu:
  Confirmed

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