clone3 should either fail with ENOSYS (hidding the system call) or succeed. glibc will soon start using clone3 for Tigerlake hardware enablement (but the change will happen on all architectures for consistency). Thanks.
I don't think it will fail with EPERM, but I guess we'll find out. The sandboxing code is a bit confusing to me.
*** Bug 1985800 has been marked as a duplicate of this bug. ***
Well, I just got bit by the glibc starting using it as per bug #1985800, and it isn't throwing ENOSYS *or* EPERM. [ 3377.717182] potentially unexpected fatal signal 31. [ 3377.797210] CPU: 0 PID: 5935 Comm: chrome Tainted: G T 5.14.0-rc1-next-20210714-dirty #19 d24ebf564a0c1611935300e71924884963eef3a1 [ 3377.877246] Hardware name: TOSHIBA Satellite C55-B/ZBWAA, BIOS 5.00 07/23/2015 asm-generic/errno-base.h:#define EMLINK 31 /* Too many links */
(In reply to Valdis Kletnieks from comment #3) > Well, I just got bit by the glibc starting using it as per bug #1985800, and > it isn't throwing ENOSYS *or* EPERM. > > [ 3377.717182] potentially unexpected fatal signal 31. > [ 3377.797210] CPU: 0 PID: 5935 Comm: chrome Tainted: G T > 5.14.0-rc1-next-20210714-dirty #19 d24ebf564a0c1611935300e71924884963eef3a1 > [ 3377.877246] Hardware name: TOSHIBA Satellite C55-B/ZBWAA, BIOS 5.00 > 07/23/2015 > > asm-generic/errno-base.h:#define EMLINK 31 /* Too many links */ Signal 31 is SIGSYS, so it's also seccomp related. It's an emulation trap. In-process emulation will not work in this context because for correctness, glibc needs to disable signals before calling clone3.
Gaah. I was looking at errno, not signal numbers. -ENOCAFFEINE :)
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
FEDORA-2021-78b9d84299 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-78b9d84299
FEDORA-2021-02b301441f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-02b301441f
FEDORA-2021-6225d60814 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6225d60814
FEDORA-2021-02b301441f has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-02b301441f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-02b301441f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6225d60814 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6225d60814` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6225d60814 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-78b9d84299 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-78b9d84299` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-78b9d84299 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6225d60814 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-78b9d84299 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-02b301441f has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.