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 3EDE0C38145 for ; Thu, 8 Sep 2022 22:13:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD83B8D0003; Thu, 8 Sep 2022 18:13:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B86EF8D0001; Thu, 8 Sep 2022 18:13:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A27648D0003; Thu, 8 Sep 2022 18:13:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 93D4D8D0001 for ; Thu, 8 Sep 2022 18:13:35 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5EDA440214 for ; Thu, 8 Sep 2022 22:13:35 +0000 (UTC) X-FDA: 79890320790.23.BD9CFD0 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf24.hostedemail.com (Postfix) with ESMTP id CBFEF1800A1 for ; Thu, 8 Sep 2022 22:13:34 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]:58992) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oWPm8-002ssu-S0; Thu, 08 Sep 2022 16:13:32 -0600 Received: from ip68-110-29-46.om.om.cox.net ([68.110.29.46]:46196 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oWPm7-001KLb-OV; Thu, 08 Sep 2022 16:13:32 -0600 From: "Eric W. Biederman" To: Christian Brauner Cc: Andrei Vagin , Alexey Izbyshev , Florian Weimer , Dmitry Safonov <0x7f454c46@gmail.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kees Cook References: <87czcfhsme.fsf@email.froward.int.ebiederm.org> <874jxkcfoa.fsf@email.froward.int.ebiederm.org> <20220908081003.sjuerd5wiyge4jos@wittgenstein> Date: Thu, 08 Sep 2022 17:13:08 -0500 In-Reply-To: <20220908081003.sjuerd5wiyge4jos@wittgenstein> (Christian Brauner's message of "Thu, 8 Sep 2022 10:10:03 +0200") Message-ID: <87v8pxa51n.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1oWPm7-001KLb-OV;;;mid=<87v8pxa51n.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.110.29.46;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX1/Jv5/mtihLYgg6/yEe7fE8pTsvhTbkicE= X-SA-Exim-Connect-IP: 68.110.29.46 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: Potentially undesirable interactions between vfork() and time namespaces X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf24.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662675214; a=rsa-sha256; cv=none; b=YFsUJrpm57N0MoYKs0mRvFatH9g840SPo+6g9UcDfehgdquLjNPBkjOkb/9MF/5PKTZkTr v1jP5CtVR2PYDWitlRt/qmmFKgSM6kk0OoA24GatNpBJ/c2tXEW/Jf/4/honejfBTHR72b etfWLgbon6V3VVthfOCaZYwW4wo+lYs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662675214; 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; bh=WgaSYrz6AJbUxuroc9gTvf4PEtYunqCG7AoUF5dtmVI=; b=Hd5ln01Hf7ys9i45iST19SIlUCXPPunpPTlx+QoM50ISl3TPt12MmDUq4lCSA3lUNmJSSa mNJNeINmlRf0k3Hb8O9kSrrmuHl3ec7IRlk4OmAqteZ/bHq/8ODbRGE1OGf8rZUEo3yBn0 Yf/Jm2S5VJsCwKpgv93SgWf1KFvuJyY= Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf24.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Stat-Signature: 6kty5ofzhgzhf1e7atyjjnasanpq4uho X-Rspamd-Queue-Id: CBFEF1800A1 X-HE-Tag: 1662675214-983786 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: Christian Brauner writes: > 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. If I understand the description of lxc/lxd correctly the proposed change will not effect lxc/lxd, as the time namespace is already installed before exec. If anything what is proposed would potentially allow lxc/lxd to be simplified in the future by removing the setns. Are you then requesting the behavior of the time namespace not change when the proposed change will not effect lxc/lxd? Eric