[Group.of.nepali.translators] [Bug 1576066] Re: 32bit glibc calls old socketcall() syscall, causing seccomp problems
** Also affects: glibc (Ubuntu Zesty) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Zesty) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Artful) Importance: High Status: Fix Released ** Also affects: libseccomp (Ubuntu Artful) Importance: High Status: 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 Status in glibc source package in Zesty: New Status in libseccomp source package in Zesty: New Status in glibc source package in Artful: Fix Released Status in libseccomp source package in Artful: 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 ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1576066] Re: 32bit glibc calls old socketcall() syscall, causing seccomp problems
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 ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1576066] Re: 32bit glibc calls old socketcall() syscall, causing seccomp problems
** Also affects: glibc (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Trusty) Importance: Undecided Status: New -- 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: Confirmed Status in libseccomp package in Ubuntu: Confirmed Status in glibc source package in Trusty: New Status in libseccomp source package in Trusty: New Status in glibc source package in Xenial: New Status in libseccomp source package in Xenial: New 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 ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
