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 27C05C54EE9 for ; Wed, 7 Sep 2022 17:15:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5AFB6B0072; Wed, 7 Sep 2022 13:15:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0B346B0073; Wed, 7 Sep 2022 13:15:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D2836B0074; Wed, 7 Sep 2022 13:15:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7EFA86B0072 for ; Wed, 7 Sep 2022 13:15:56 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3D16441070 for ; Wed, 7 Sep 2022 17:15:56 +0000 (UTC) X-FDA: 79885941912.22.9F8DB36 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf21.hostedemail.com (Postfix) with ESMTP id F34321C0089 for ; Wed, 7 Sep 2022 17:15:55 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id d82so1659121pfd.10 for ; Wed, 07 Sep 2022 10:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=LP6BhElerZIzGOprmbC4BLmDZ102mvint9Kn4+cKMbM=; b=mzQyZB40KCiXLMDuKL5lB6eLpwJqIqWqeSH5sGLa5V/Qs0kYdwWCkhQ0NzpWLxRZJq 7LvN5V/9BoNq1y+PH3OgUtapAwRnn1jW/HpC97/RUwU55XpidRixHzaxHpiTQOejmM4F 7eKwGh2mGNbCKbAuNWCLWl4u90vI7hqCxt5hkBgV7xU1vKizbhObwVONuz/bL/imPtSh PM+eDDKoyfKAxqCBrG6S6gjAmqdaolMmuD27K58kl0Eg4lx9y10jJ7H0ipjk23POshRp K4om9jKIL1T6/xlLsy//L9ItJYnculoJ4Lp3sWrvLLG8LbDQbFYqUKdUaK2mev8B4EXt m7tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=LP6BhElerZIzGOprmbC4BLmDZ102mvint9Kn4+cKMbM=; b=xyCVPDbN5+J1SF/MbrS3jGsmPbpSLjMVCpkbn+b78ZAbLXfOvG8gCheew7PDhSaXmc zj74jXHc1/EIvytyzPMuguFukiO6+HgpB90Qh06X3ETAOzXMyc4j/8tbYKh27znlX+af aLcf4klmqb3GAGTXWgyoCUdFi52pcXWVmSsgjBUf32S0nUcX3+9rGGDEzL605P6Rm6c8 +tCgCXOvjRLydWd1Szta5+HvH1FkjAjeOR4npkLNXm8vMDA4OXAzJzRIk+Ojxdy6vWpI vCHFj5/7Byw7+gGMsaDYt/vA4aEzJRiJyjItAhufgGE/M6IhQtNrRcc2tQhcyzQ4Vsfb cqOA== X-Gm-Message-State: ACgBeo0DyGNcKhTydxXJcBeT1LCPqzR/0aU86BxdgIKPFQFdjFKn/vwb snve7nDYd4y1SaLvdqeBDBE= X-Google-Smtp-Source: AA6agR7xlWPnpZhoywgpWJQYI+8OBmi56gLna4F7CRyVvZXepOcLWT4CPLJ016j4BEooqnen7Z19iQ== X-Received: by 2002:a65:6c07:0:b0:41d:9ddd:4266 with SMTP id y7-20020a656c07000000b0041d9ddd4266mr4283039pgu.326.1662570954707; Wed, 07 Sep 2022 10:15:54 -0700 (PDT) Received: from gmail.com ([2601:600:8500:5f14:d627:c51e:516e:a105]) by smtp.gmail.com with ESMTPSA id g9-20020a635209000000b0042ad3214a88sm10949534pgb.74.2022.09.07.10.15.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 10:15:54 -0700 (PDT) Date: Wed, 7 Sep 2022 10:15:51 -0700 From: Andrei Vagin To: Alexey Izbyshev Cc: "Eric W. Biederman" , Florian Weimer , Christian Brauner , 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: References: <87czcfhsme.fsf@email.froward.int.ebiederm.org> <874jxkcfoa.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662570956; a=rsa-sha256; cv=none; b=MCzbf9I22zpflMZrz7vYq+m/mqlv0REO7xPF9jXKnh7ci5mb1WzlXkDhX0cyWScD82qDf5 pPNIUcj9K1wA/cVSDWQxR3mUYla8/exTI5o7VRc3AIYKuzNUoFvfnT72yErM4XqKVYU4Xg Udf51XdUarASwdxO9v5JARKtagVCDGY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mzQyZB40; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of avagin@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=avagin@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662570956; 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=LP6BhElerZIzGOprmbC4BLmDZ102mvint9Kn4+cKMbM=; b=mqw+aLWXfW/rtAnNTUKcXCk+qw3KGjUHhfP/jEGQUFVA8s2dDbTxAKpzVQWO4NMMred5k4 QP3wbakhAUjqI9RrqTC/qxyyZgMEqtvMuMaUr17VHwk5bQOwEdWclG3bewoRrwaz3KjoNQ SNeUlalDuaoZGR+mkBsU0zPw+bGwkBY= X-Rspamd-Queue-Id: F34321C0089 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mzQyZB40; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of avagin@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=avagin@gmail.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: n53ty6pxytn7zs411oe7ske1oss8d639 X-HE-Tag: 1662570955-397163 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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 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. > > The "unshare" tool from util-linux will also change behavior if called > without "--fork" (e.g. "unshare --user --time"), but that would be unusual > usage (just as for "--pid"), so most people probably don't do that (or don't > care about the time namespace of the exec'ed process, but care only about > its children).