[Bug 1576066] Re: 32bit glibc calls old socketcall() syscall, causing seccomp problems
Launchpad Bug Tracker
1576066 at bugs.launchpad.net
Wed May 11 18:31:22 UTC 2016
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: glibc (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.
32bit glibc calls old socketcall() syscall, causing seccomp problems
Status in glibc package in Ubuntu:
Status in libseccomp package in Ubuntu:
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
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.
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:
More information about the foundations-bugs