From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2882 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Handle ENOTDIR in pathexec_run Date: Wed, 19 Feb 2020 08:18:31 +0000 Message-ID: <5afb3f20-239b-f09a-c696-fe36d141b2cd@NTLWorld.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="53623"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 To: Supervision Original-X-From: supervision-return-2471-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Wed Feb 19 09:18:41 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1j4KZ7-000Dif-2g for gcsg-supervision@m.gmane-mx.org; Wed, 19 Feb 2020 09:18:41 +0100 Original-Received: (qmail 2375 invoked by uid 89); 19 Feb 2020 08:19:00 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 2368 invoked from network); 19 Feb 2020 08:19:00 -0000 X-Originating-IP: [86.10.101.211] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=OaYs8SbY c=1 sm=1 tr=0 a=FQ5CjUvp3JFI4KFGyeqcZw==:117 a=FQ5CjUvp3JFI4KFGyeqcZw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=UN4CLpCSmgc1gO3EwhQA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1582100312; bh=PRj5L21eUA5qzB9dwqKd89ewQB5g6E+NPz36JGf/+CM=; h=Subject:To:References:From:Date:In-Reply-To; b=WZdhulwBFvxtkWEatIi3LZWO90SinKhRau5bcXr9jP0RZNecsuRycMGK0WqEmIO4n QJpWLS4sF8nIxGwBBdgfBnERFpAKPSbi5w73uYBQ2UT/pluKCp6r+0BdBp4xxGoCFW MOaiuX/+WC9toNH8KtxadtSNL+eLbXqXIG4upaOjaRQrRSF88VLCrPwMT6Cq1dGsh4 DOoiqNh3ktFAVEu+amIh/lt3a4r3995Btv7osonTxIARg4hP105GSRBKsOC0NS56hu Mf5UUu8eVMgzdAJhQ0qYVWb76xTldoorSdmAJvmC0oWu5Zxb00k5hqP0whdo5WW3QT 18P8Xpg0YX7kQ== In-Reply-To: X-CMAE-Envelope: MS4wfHNlZIqBYU6u+V6wZfngUPqZtdH6s4l9EemsF+pRk2fbF7xHqr/5vzHb+n+TDUnjfBnwNqNCcw8t0Tc4QSs551DQYYLHXkkpjTUV1762t9t84Xxz26Sh X7EnSdEyhMnFijNikv2bABsrLrXjVXxstPIgKaexodA6CxjLw0Jryu83OGc+i+uDNoLAuBQlCcRMZOf4vGoycxd5dMZIHRspySlcR2obe2csiuqUMyroiXSX Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2882 Archived-At: Jacob Vosmaer: > The patch below makes runit ignore this type of bad path entry. > What do you think? > It's not good enough. I was all set to apply this to djbwares, as the runit code for pathexec is actually Daniel J. Bernstein's original code. But it highlighted some basic problems of running execve() in a loop to do a PATH search. Simply put: One wants to (largely) ignore the error if there's a problem with the directory prefix from the search path; and one wants to retain the error if there's a problem with the final pathname component, the name that is being searched for or the actual node that it names. Unfortunately, execve() can return EACCESS in both cases, and simply deciding to exit the loop based upon nothing but the errno value is therefore an unworkable strategy. If you look at the BSD C library in FreeBSD, you'll see that it attempts to distinguish between the two cases in its execvpe() by calling stat() on error. If the stat() succeeds, then the problem cannot be with the directory prefix. So it remembers the EACCESS, which must be a problem with the file itself. If the stat() fails, then the problem is with the directory prefix (or with symbolic link traversal, hence the use of stat() not lstat()) and it largely ignores the EACCESS. If you look at the internal_execve() function in the next release of the nosh toolset, you'll see that I've used a different design and made use of (relatively, they still being over a decade old) newer API functions, instead. The code uses openat() on the path prefixes with O_DIRECTORY (and O_CLOEXEC), if that fails largely ignoring that error and continuing to the next PATH component. It then uses, relative to that file descriptor, openat() with O_EXEC and then fexecve() for the final component (which it also this way does not have to do string concatenation with), retaining that error if that fails. Things are slightly complicated by some trickiness relating to executable scripts with interpreters, but that's the gist of it. pathexec_run() needs similar attention.