Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #2116442 +++
This commit
commit 769071ac9f20b6a447410c7eaa55d1a5233ef40c
Author: Andrei Vagin <avagin>
Date: Tue Nov 12 01:26:52 2019 +0000
ns: Introduce Time Namespace
added support for unshare(CLONE_NEWTIME), but the initial implementation was incompatible with vfork. This has been fixed in this commit (merged into Linux 6.0):
commit 133e2d3e81de5d9706cab2dd1d52d231c27382e5
Author: Andrei Vagin <avagin>
Date: Sun Jun 12 23:07:22 2022 -0700
fs/exec: allow to unshare a time namespace on vfork+exec
Right now, a new process can't be forked in another time namespace
if it shares mm with its parent. It is prohibited, because each time
namespace has its own vvar page that is mapped into a process address
space.
When a process calls exec, it gets a new mm and so it could be "legal"
to switch time namespace in that case. This was not implemented and
now if we want to do this, we need to add another clone flag to not
break backward compatibility.
We don't have any user requests to switch times on exec except the
vfork+exec combination, so there is no reason to add a new clone flag.
As for vfork+exec, this should be safe to allow switching timens with
the current clone flag. Right now, vfork (CLONE_VFORK | CLONE_VM) fails
if a child is forked into another time namespace. With this change,
vfork creates a new process in parent's timens, and the following exec
does the actual switch to the target time namespace.
Suggested-by: Florian Weimer <fweimer>
Signed-off-by: Andrei Vagin <avagin>
Acked-by: Christian Brauner (Microsoft) <brauner>
Signed-off-by: Kees Cook <keescook>
Link: https://lore.kernel.org/r/20220613060723.197407-1-avagin@gmail.com
Without this kernel change, we'd have to patch glibc and various other libraries that provide generic process-start facilities that are based on vfork, so that applications can call unshare(CLONE_NEWTIME) and still launch new processes.
(In reply to Florian Weimer from comment #0)
>
> commit 133e2d3e81de5d9706cab2dd1d52d231c27382e5
> Author: Andrei Vagin <avagin>
> Date: Sun Jun 12 23:07:22 2022 -0700
>
> fs/exec: allow to unshare a time namespace on vfork+exec
It turns out, we need to put this bz on hold.
Firstly, it is not that trivial to backport this patch as I thought,
but this is solvable.
The main problem is that this patch was reverted upstream, see the
commit 33a2d6bc3480f9f ("Revert "fs/exec: allow to unshare a time
namespace on vfork+exec"").
People are working on another version, I think we need to wait until
the new patch is merged upstream.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: kernel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2023:2951