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 19127 invoked from network); 2 May 2022 20:49:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 20:49:58 -0000 Received: (qmail 5812 invoked by uid 550); 2 May 2022 20:49:56 -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 5789 invoked from network); 2 May 2022 20:49:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651524584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1y1eF5WLKq2T+QtOdFxWBpxLZm2T7iByDHhG1WJCtt0=; b=LRH6Md57G8AYyecPOJnDk0imcjCOYzQoN33nrVx8Qx+gx9+rMKX6RZuDYhlSwlz1rye3NU 1vVZcTGcETvYf21jUPtWkXnKLEInbg1sP1dCylWGTGRCQagvDbPMtCPE9YkbGj1o+CnMHw dJmLyJUSEwK4KSppIsRLt8XKtmVCluA= X-MC-Unique: gupKABXFOQyRsqW0sPyK5w-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:references:from:organization:in-reply-to :content-transfer-encoding; bh=1y1eF5WLKq2T+QtOdFxWBpxLZm2T7iByDHhG1WJCtt0=; b=OABLaAFWTslcbZ0Nx0MIXC4UlajwX5TcGkvtgM9VZXlv6qO+QNAoUslrUDOP3HRiR2 9rY7g82SEitEe4WxjW3haNyFizbhLt6R6aPon8n766HzRuIXbECXvxPsQrYzhoP21eRt fP6GbHeJJfoPsYjPhUqWZwpOEGoJMsasnB8FhRfCmi5kj1X2dkAbW8oobrOi01bm0tSi MzCyImdBoaTqx9OCF57lLEvemkcMfCG6eTf6TsvgF0Mf5pR5EtZ9dJAjSifiLKC5gVr7 1PKudlZIasUxPJGW9g4W7BNhoWpdORWkbNmQDFZrq0sYJRbhU/3toPmWclMBngb7orDd 06aw== X-Gm-Message-State: AOAM532aVyXQPzYoJCOwiRD4LNgyL+f+etKZR+HprsAd+lu1rsZ4+Jif qpTwQwgoyQAlPzDIuGFExPUm+G/cMJtt6XSTk4ZdLcyjjo032sNYFJbT8OA/vv+3BUuXSrxChAi OLNPnsIxSAHFGjqvM3R8cNfdQWa+vxYpTcNLXaWBMMKKa63e7N+Gl5JKAhppLUfGwzUc= X-Received: by 2002:ad4:4025:0:b0:456:3493:fb33 with SMTP id q5-20020ad44025000000b004563493fb33mr11146251qvp.120.1651524581749; Mon, 02 May 2022 13:49:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhoOsl9WSQgnW1Ig4B2Ma+HiAn/OANeLB9Ycz47JSoxZB9bGWtQeqYSfUEPlShz6USkmPXFQ== X-Received: by 2002:ad4:4025:0:b0:456:3493:fb33 with SMTP id q5-20020ad44025000000b004563493fb33mr11146232qvp.120.1651524581423; Mon, 02 May 2022 13:49:41 -0700 (PDT) Message-ID: Date: Mon, 2 May 2022 16:49:39 -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, Alexey Izbyshev References: From: Carlos O'Donell Organization: Red Hat In-Reply-To: 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 15:26, Alexey Izbyshev wrote: > I've also opened a bug about this in glibc[2]. Maybe libcs could > coordinate in how they handle this case. Speaking as a glibc maintainer. Either the kernel supports vfork or it doesn't. A time namespace, or a seccomp filter are all the same problems, and we should return the error to userspace. Adding code which will only be exercised in the event that a time namespace is in use is going to result in increased long-term maintenance costs. It also results in unexpected surprise behaviour when the developer runs under a time namespace e.g. more memory usage, different code paths taken etc. Rather than add long-term maintenance and surprise developers my suggestion is to fail the posix_spawn. Users can take this up with the kernel to add support for vfork in time namespaces, or with their sandboxing technology provider. There might be exceptional cases where we need to add fallbacks, but I can't see that this is one of those cases. For example clone3 to clone2 fallback is sensible. My impression was that time namespaces as they are today were added primarily to support CRIU process freeze and restore with different monotonic clock offsets[1]. If CRIU needs this to work then it would be more effective to fix the kernel, than to fix every userspace you need to freeze to support fork fallback. -- Cheers, Carlos. [1] https://lore.kernel.org/lkml/158016896588.31887.14143226032971732742.tglx@nanos.tec.linutronix.de/