Public bug reported: 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. ** Affects: glibc (Ubuntu) Importance: High Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576066 Title: 32bit glibc calls old socketcall() syscall, causing seccomp problems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1576066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
