From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120922 invoked by alias); 6 Jun 2018 13:21:29 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 120123 invoked by uid 89); 6 Jun 2018 13:21:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f181.google.com Received: from mail-qt0-f181.google.com (HELO mail-qt0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Jun 2018 13:21:26 +0000 Received: by mail-qt0-f181.google.com with SMTP id q6-v6so6262539qtn.7 for ; Wed, 06 Jun 2018 06:21:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=50/7VYR/vOSWZ5E8+QAiMwIVwAYZtmQPKSgWdOn3Yrc=; b=qXKAPK5FKuzHYLTnVxcGxoGTBuAQUD+lGhjfBD+PmWFj/AW0qwN8pUJV/SzEcxjQ3g gvA5pLgPopFT0VNXlK+WdwY0FkWbCz8VWUrSn67jyxhfTDjMhSyHHel4l0uwWYXLeRyD 0CtUKsihAUzFLl/zoG3CmCZB6CDSTqA2MkncHVFri1u25sZ+34PBKLdeR+pInLlgJHIw 9piYK0l+06hYj0Hv/3Go5mPWjROGM2Lkks7o15VJ0Ho4sewx7pj18Nh4j4wTZRPiVxbn K5eSfJgJudJrGP9MJ6heh1meEIKyiF+V2XrsyANYfo3dyiShqDdDhiUsiiTHs0ZBReKB nrjQ== X-Gm-Message-State: APt69E2bq7sB1Ugs4dfQXG1au85+7tS+FzAdE0ERagTmLXV0B1W8eCGG qcKgzhvAequ7BjQGx08lJdhkC3U4YNY= X-Google-Smtp-Source: ADUXVKIpWohFmiMEoaqx48rGRogDOK8gM2BLKGjEz5sD/IyOQOiyUsQ2UInWdOaDAz5jT2W+bPZj+Q== X-Received: by 2002:ac8:1978:: with SMTP id g53-v6mr2774333qtk.282.1528291284284; Wed, 06 Jun 2018 06:21:24 -0700 (PDT) Received: from [10.0.0.105] ([179.159.11.160]) by smtp.googlemail.com with ESMTPSA id o2-v6sm26852109qtf.91.2018.06.06.06.21.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 06:21:23 -0700 (PDT) Subject: Re: posix_spawn and script execution To: libc-help@sourceware.org References: From: Adhemerval Zanella Openpgp: preference=signencrypt Message-ID: Date: Wed, 06 Jun 2018 13:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00013.txt.bz2 On 05/06/2018 16:05, Daniel Drake wrote: > Hi, Hi, > > The posix_spawn man page says: > >> The only difference between posix_spawn() and posix_spawnp() is the >> manner in which they specify the file to be executed by the child >> process. With posix_spawn(), the executable file is specified as a >> pathname (which can be absolute or relative). With posix_spawnp(), the >> executable file is specified as a simple filename; the system searches >> for this file in the list of directories specified by PATH (in the same >> way as for execvp(3)). For the remainder of this page, the discussion >> is phrased in terms of posix_spawn(), with the understanding that >> posix_spawnp() differs only on the point just described. > > That seems rather definitive in communicating that there are no other > differences other than the path-searching behavioural aspect. The man-pages is not the canonical documentation for glibc, but rather its own manual [1] (this is a common misconception). And since for posix_spawn{p} there is no canonical documentation, the usual expectation is it should follow the standard, in this case POSIX in this most recent version. We try to document any deviation or extension, but it might be cases where documentation is not on par with implementation (patches are welcome btw). > > However, I have found another difference: > > posix_spawnp() can execute scripts, by that I mean a text file that > has executable permissions that does not have a shebang. When used in > this way, it will use the shell to execute the script. > > You can try this by taking the sample program in the posix_spawn man > page and switching it between posix_spawn/posix_spawnp and launching a > script created with: > > echo "/bin/echo hello" > test.sh > chmod a+x test.sh > > posix_spawn fails to execute it, but it runs fine with posix_spawnp. > > Is this an omission in the man page that should be corrected, to state > that a second difference between posix_spawn and posix_spawnp is that > the spawnp variant can execute scripts, in the same way that exec(3) > documents the exact same behavioural exception for execlp/execvp? > > Or is the presence of this behavioural difference a bug in glibc? > > Looking at the history, posix_spawn() used to be able to launch > scripts too, but this behaviour was changed here: > https://sourceware.org/bugzilla/show_bug.cgi?id=13134 > > The resulting commit looks like it tries to make the change both for > posix_spawn and posix_spawnp, in that it creates compat versions of > both functions that set SPAWN_XFLAGS_TRY_SHELL while also omitting > that flag from the "fixed" functions: > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d96de9634a334af16c0ac711074c15ac1762b23c > > however ultimately posix_spawnp script execution is still possible > today because the spawnp variant uses __execvpe. Check the source code > for __execvpe and you can clearly see the script exec ENOEXEC > fallback, and I believe that's why posix_spawnp can run scripts. > > Clarifications appreciated! > > Thanks > Daniel This is clearly a regression, thanks for bring this up. The posix_spawnp should not try to ENOEXEC files as default, only in compatibility mode. Thanks to bring this up, I will work on a patch. [1] https://www.gnu.org/software/libc/manual/