lkml.org 
[lkml]   [2022]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] fs/exec: allow to unshare a time namespace on vfork+exec
Date
* Kees Cook:

> On Sun, Jun 12, 2022 at 11:07:22PM -0700, Andrei Vagin wrote:
>> 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.
>
> This seems like a very special case. None of the other namespaces do
> this, do they?

I think this started with CLONE_NEWPID, which had a similar delayed
effect with unshare: it happens only after fork, not for the current
process image. I think it's just a limitation of the unshare interface.
Some of the effects simply have to be delayed due to their nature.

Thanks,
Florian

\
 
 \ /
  Last update: 2022-06-15 09:54    [W:0.074 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site