Bug 2116442

Summary: kernel: Backport vfork support for time namespaces
Product: Red Hat Enterprise Linux 9 Reporter: Florian Weimer <fweimer>
Component: kernelAssignee: Oleg Nesterov <onestero>
kernel sub component: Process management QA Contact: Chunyu Hu <chuhu>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: cye, onestero
Version: 9.2Keywords: Triaged
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-5.14.0-242.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2116444 (view as bug list) Environment:
Last Closed: 2023-05-09 07:59:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2116444    

Description Florian Weimer 2022-08-08 14:13:17 UTC
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.

Comment 2 Oleg Nesterov 2022-10-17 12:04:09 UTC
Just in case, let me quote my comment https://bugzilla.redhat.com/show_bug.cgi?id=2116444#c2

(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.

Comment 16 errata-xmlrpc 2023-05-09 07:59:50 UTC
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:2458