From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25216 invoked from network); 2 May 2022 21:32:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 21:32:11 -0000 Received: (qmail 6016 invoked by uid 550); 2 May 2022 21:32:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5996 invoked from network); 2 May 2022 21:32:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651527118; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w08vWfgbEP1kuc0b2khQQO0SC7l+17NGqrLw33H83ys=; b=TuRwJH8GTcUualhjeHObmutUvJh+mwj1Q8GS+2tUZRx9BR+l2eitrRYy4eZgul9YzN9+lG yTBOCDm3MVGbCVfim86JvpXiZQVX+hSkpLIlpnqCba/tbdH/87tQ3THaxQyujnTq1iNaGX u8CyidtQia9H5W0jtKLfyWJq46i6ozc= X-MC-Unique: aVKpDlCGNLiJBbUI6JIyRw-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=w08vWfgbEP1kuc0b2khQQO0SC7l+17NGqrLw33H83ys=; b=hroOqVEF7Qh6meymuYDtWklS0gu/POjQo7ab1/q8orQAXyHbzIb0vXHgdWXcBz7yeT rui7IDF15eNy0kk+sSX8U71xRe+ZBdLlt0YGq+0XR0PZGOpo1QsTHpJPjK4OlwatFGdl M2XRIJI9wZVcJ+Xr4vS3XjQsn7YqdFsyq+JNLbOteMiBeeKdDuZ8CMty64iDPhul3DWx 7XKLYbbNgvwzocuGyy1nvLT3GTxFSJiSlf1GS9fL7Gl/J4jbMeGXciQksui/Ugmf7ncB gKlvBvn0L3ljJeDpGCYVxATTorLm1jd+DJ2uoCfEKDzXrHPAjV8akaSlGT3x9Mt9m6pM 9gfQ== X-Gm-Message-State: AOAM5304w62cyc6kGHAYqwYjwtiWj6gNDdXBoTU3cyRiCXSt8caK61j8 DDLOZC3B1UZbOabFY9IkHGi+k5T3KYsCwa1zuIwH8lY8IOUEpGkxXNxCQVG50sWNmWanyJjTkjo lqgc0a2HXzHCKGAKE0yIV/Aie4/SkRPGsWVImYtRzVo0F3cAFM5msAIoNEqvZHsbImEQ= X-Received: by 2002:ac8:588b:0:b0:2f3:92eb:16d4 with SMTP id t11-20020ac8588b000000b002f392eb16d4mr12169626qta.252.1651527115777; Mon, 02 May 2022 14:31:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4U4s52LivZP7ApyWVPcWobnRj8sBjSWRTZVs4OkYKEnax0beyd2YUexG48DMjtt//0hYm/Q== X-Received: by 2002:ac8:588b:0:b0:2f3:92eb:16d4 with SMTP id t11-20020ac8588b000000b002f392eb16d4mr12169601qta.252.1651527115452; Mon, 02 May 2022 14:31:55 -0700 (PDT) Message-ID: <5e002596-2450-98e0-f06b-39c458dcaf71@redhat.com> Date: Mon, 2 May 2022 17:31:53 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: musl@lists.openwall.com, Florian Weimer , Rich Felker Cc: Alexey Izbyshev References: <20220502211856.GR7074@brightrain.aerifal.cx> <8735hr4ogc.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <8735hr4ogc.fsf@oldenburg.str.redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=carlos@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] vfork()-based posix_spawn() has more failure modes than fork()-based one On 5/2/22 17:25, Florian Weimer wrote: > * Rich Felker: > >> I'm trying to understand how this comes to be. The child should >> inherit the namespaces of the parent and thus should not be in a >> different namespace that precludes spawn. I'm guessing this is some >> oddity where unshare doesn't affect the process itself, only its >> children? If so, it seems like a bug that it doesn't affect the >> process itself after execve (after unshare(1) runs your test program), >> but that probably can't be fixed now on the Linux side for stability >> reasons. :( > > It's about fundamentally conflicting requirements. > > The vDSO data mapping needs to store the time offset, so it has to be > distinct from the original namespace. vfork preserves the VM sharing. > It's not possible to do both things at the same time. > > unshare(CLONE_NEWTIME) should have been specified to only take effect > after execve, when the vDSO is remapped anyway. Can we ask some kernel developers for an opinion? -- Cheers, Carlos.