From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50A05ECAAD5 for ; Thu, 8 Sep 2022 08:10:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C49F36B0072; Thu, 8 Sep 2022 04:10:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF9BA6B0073; Thu, 8 Sep 2022 04:10:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC0EA8D0002; Thu, 8 Sep 2022 04:10:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 999966B0072 for ; Thu, 8 Sep 2022 04:10:12 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 60FCB1A1A43 for ; Thu, 8 Sep 2022 08:10:12 +0000 (UTC) X-FDA: 79888195464.11.985D794 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf29.hostedemail.com (Postfix) with ESMTP id E255E1200B5 for ; Thu, 8 Sep 2022 08:10:11 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 62A0DB81FCE; Thu, 8 Sep 2022 08:10:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F154C433C1; Thu, 8 Sep 2022 08:10:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662624609; bh=LMauM8SkFMkfOPkj98kj47U4j0tAP2vl9skTIW/vjGk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oDix0JGmh6nCZ3ji6fpKUFzAf3Mqje4BvBa8lqfIbB/GpbfoXI987MCp/+BWD82fK 2L5zFQUb0mgCxq8dQfsU8Lq19JH1uvX1WvIDra0Do8ICB5ukgGClrjqHOie5ISLSoV SdkY9+IY37IQXBPMuTPfu9sqpTceX7LkEu50qdtfZEbymiorg6TsddQW89Tt3yICnd 6/Z6NiBcATVxjP3/RhA/tB9qRStbNYkt7kRpimPPOTsF7oLOpJrEz5HB42hmKsdN4a cej6azOpbXkNE8xnlJ6XJeHA/XqPhdHXVgivKpequKSbBPXYdE72ZufZxJqXaBSZRu GL/939V1FPtqA== Date: Thu, 8 Sep 2022 10:10:03 +0200 From: Christian Brauner To: Andrei Vagin Cc: Alexey Izbyshev , "Eric W. Biederman" , Florian Weimer , Dmitry Safonov <0x7f454c46@gmail.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kees Cook Subject: Re: Potentially undesirable interactions between vfork() and time namespaces Message-ID: <20220908081003.sjuerd5wiyge4jos@wittgenstein> References: <87czcfhsme.fsf@email.froward.int.ebiederm.org> <874jxkcfoa.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662624612; a=rsa-sha256; cv=none; b=sAxqBZCTPVY7j3e9bysvqJRJ7IwdOa2LUMmJxJZ1IzqzwE2MkE+4FTf7C1SSfJgXBU+qWg 6MYyzITHHHrQkAZigMFrMLfoulj5ytUPeR4tKofsuPDx80vTQSJmfhG+8ExxLhfAEp3wiq YrbpNEhsXICCsEBD0H16tLcFW3qVB/M= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oDix0JGm; spf=pass (imf29.hostedemail.com: domain of brauner@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662624612; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ipxQx5n+zgKK9rskd7HG/JGAZtrOwI2OTuGj6mQF21g=; b=yGFelDlIAifMeU8x4pBcWjPV/TcH9vWnVbIYtguhtaZBl6sBwdkprOUAK68fsgNuhiKVXN Cpv77Wt1waRGd1IcGcxQia1JCvE830zS7bjUF5BREiAIfWXPIQo5Waku4hrJtsp8nbQswP wjXZI83kwVp5lNYIQeRMHC1LRRLxZDM= X-Rspamd-Queue-Id: E255E1200B5 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oDix0JGm; spf=pass (imf29.hostedemail.com: domain of brauner@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: tqksumxx4wypngdib5ixq67kb1oawzso X-HE-Tag: 1662624611-433803 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 07, 2022 at 10:15:51AM -0700, Andrei Vagin wrote: > On Wed, Sep 07, 2022 at 08:33:20AM +0300, Alexey Izbyshev wrote: > > > > > > That is something to be double checked. > > > > > > I can't see where it would make sense to unshare a time namespace and > > > then call exec, instead of calling exit. So I suspect we can just > > > change this behavior and no one will notice. > > > > > One can imagine a helper binary that calls unshare, forks some children in > > new namespaces, and then calls exec to hand off actual work to another > > binary (which might not expect being in the new time namespace). I'm purely > > theorizing here, however. Keeping a special case for vfork() based only on > > FUD is likely a net negative, so it'd be nice to hear actual time namespace > > users speak up, and switch to the solution you suggested if they don't care. > > I can speak for one tool that uses time namespaces for the right > reasons. It is CRIU. When a process is restored, the monotonic and > boottime clocks have to be adjusted to match old values. It is for what > the timens was designed for. These changes doesn't affect CRIU. > > Honestly, I haven't heard about other users of timens yet. I don't take > into account tools like unshare. LXC/LXD does unshare(CLONE_NEWTIME) // write offsets to /proc/self/timens_offsets timens_fd = open("/proc/self/ns/time_for_children", O_RDONLY | O_CLOEXEC) setns(timens_fd, CLONE_NEWTIME) exec(payload) so I agree don't change the uapi, please. But as you can see what we do is basically emulating changing time namespace during exec via the setns() prior to the exec call.