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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3369 invoked from network); 13 Oct 2020 02:47:56 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2020 02:47:56 -0000 Received: (qmail 20034 invoked by uid 550); 13 Oct 2020 02:47:50 -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 20010 invoked from network); 13 Oct 2020 02:47:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602557257; bh=QCyEnAuK5SQqSg84gHSZu0X/pTKAd/PNSgsvH7ia77M=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=K6in5kXYyZV7YIxkohGU+U8vFZ7UUrkhw1+ZXmHE94ABp+4cY7bRbNx/lnk/P6LeE xGNHYx4W4pVDR0TZHZaL9LnsYciE61cFsXAUChhsYjuoxpdDaECdlSVVG7IFd1LRah i4ElP8g6zGY6qmo5pLGXYZ7iSn36Rs2t8A5BGmqI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Tue, 13 Oct 2020 04:47:37 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20201013024737.GB7816@voyager> References: <93cbaeffbc860a145843e0380058c50e@ispras.ru> <20201012145549.GG17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:qBqexfeye13/rLy8wUfmvqofdebcHNP1KjhQkU5O5As2oxMwZao JlLvyQ13zwTz1eldIbH5ylyKsymX2LUcTfoezZxPziy9N9gyKUUZloEf0T6FWX4yYm0U+DZ /NJepooG9LLo1fVgIhL0m19ha+f2bE1xFhu/6qH2awTEKz3Q1WLma8A395uwJkTWajwiZgB qBK0d0k1gbtphGOkpd5cA== X-UI-Out-Filterresults: notjunk:1;V03:K0:72xYApWEf/I=:u5F4MbMYeVMO6r+4KK9Hig yVz4rXPqKR1UQmMJUAIeDjl1Dw0sVViSD1K4413j5LYCkSOjNu04rJmlvYIVz7Q5P7tzMQUS2 0BO4EdxI3h9PzoNet4PPdLIQUC3bv5BREBy8EArvZI6m8vJhLMTZo6Ue5PHF/zSPrtBDdXSfc rONySmHSfZLv5jaVhnmOrkjA4CGozij5dtFFFXaZ1gbiC9OjwmjUU6HPWEJB3s4KJTew+JtAI Apl5YEWdYMGOLQBu7K7leGUzU5aHjBHaHZmHqbqGpltQDWVEJHGB8ZUiSDnb7MmEffJ7y8kd3 hSlkDMbGc5XtpPSE30ESphl2DkKSYCOx4+L/Kx6njmtGcZ3sWb38N0RXsyGyxxTktMuguZGO3 RQL+7j1zfjB0lttfG9RswqhypS0F3jPN14uoBNKLWbzHVW4542PGLfBBsBuQzTXeRO65sbzjH l/gE7ISiIANRmUX6NIIXdW5OeHc19Er5u9hHW0mi9vuIassAYakZBnziGKXhK++h0LT34/cSy G90GXWXHumm0yler1sjgjoh3BkE0ymzf1pxtLVAuoqY0fkIHtLhGC1/+PYWECYPXkWFEqiD3I /E8/xHaG8JDbN3KYUkac8Ai/j3c6Fd6Srt0ifvCwzmTGDPr6xAjhrN8Q3y8fVkT2tEovdTbwo r4DpFce599U95UAS3xYfWOQcIDkkvqiALKb2+x+Jkh4BT3Qe8qUP8Ei3tG7VjOJ5Q6WIjtCig 1IHFxMsrJuwmTaUNJRTSd0rutz2+UdLPZK1MeudHJ9leq0XjnFdqDOGqV9ncB4Bv4Ai3eeM7J Lq10+WPzxz4MPVOtLL4Z1ouZTfI1EFwecX8/PdcdwXE9y5HCPRjAMqqDb/rPJ8Do2SqaWbz/m 28nBo/oQxxeG5Hg0lOHXYqPWfiAKzKB+J3i9Cap31e6JGQwCVPJHJD2frwbuihZtledAj5gBK a0WMMGy1RG1lXxD5GaqGEBTS6jlimEx41bXb60Zu0bPuPSiSu2w3m7dhm2eCuScl0CV9hUuO5 iFCMaSqT3azGu+oWKd/lVHN3Kn1gQxBL7HB0Fq/21fyTm7stKtRcC8Pjaczhw+1azbWllz9DV jACzTyvaGKoCaomatCpXgfPgxmpg+jB2+3F1Kom8nTu2P0Z9YBN4e5pXWelFFfvlBVzMCpUbn u0pF3E8HVhbmPws0dIGLV40br+2zCbz8DGCEFwnVVgFW0RA1hUW37vxA8wGJXJfqGk43DSfDq 4i/ROV6IRL6+PM9S7 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Calling setxid() in a vfork()-child On Mon, Oct 12, 2020 at 11:30:58PM +0300, Alexey Izbyshev wrote: > Unfortunately, while posix_spawn() + a helper executable would be fine i= n > many cases (more so for applications than libraries), addition of a help= er > to an existing library exposing a process creation API that can't be > implemented in terms of posix_spawn() may be not straightforward. If the > helper is just an executable file, we'll need to locate it, which may be > simply impossible when our library is called if, say, switching mount > namespaces is involved (which may be out of control of our library). > Solutions may exist (locate and open() at startup or memfd_create(), and > then execveat()?), but vfork() (+ preventing execution of signal handler= s in > the child) seems so much simpler, and doesn't add the overhead of an ext= ra > execve() too. > > Alexey > If dropping privileges is all you want, then posix_spawn() has a flag for that. And if you are foregoing portability anyway by doing anything between vfork() and execve(), might as well use clone() and do it properly. Yes, locating a helper binary is a bit of a problem. I've been recently struggling with that myself. While you can make the binary part of the main application (or library, in your case), using posix_spawn() means the binary must have a path name, so using tempfile() is out of the question (unless you use the proc file name, which is, again, non-portable). Ciao, Markus