execlp/execvp/execvpe behavior change in glibc 2.24?

[Dmitry V. Levin]

On Mon, Nov 20, 2017 at 03:56:18PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Adhemerval,
> 
> Your commit
> 
> 
>     commit 1eb8930608705702d5746e5491bab4e4429fcb83
>     Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>     Date:   Fri Jan 22 09:58:49 2016 -0200
> 
>         posix: execvpe cleanup
> 
> Appears to have caused a behavior change in execlp/execvp/execvpe,
> and I am wondering whether it was intentional.
> 
> In glibc 2.23 and earlier, if PATH was undefined, then the default
> path search list that was used included the current working
> directory as the first entry.
> 
>       if (path == NULL)
>         {
>           /* There is no `PATH' in the environment.
>              The default search path is the current directory
>              followed by the path `confstr' returns for `_CS_PATH'.  */
>           path = name + pathlen + len + 1;
>           path[0] = ':';
>           (void) confstr (_CS_PATH, path + 1, pathlen);
>         } 
> 
> Starting in glibc-2.24, we have:
> 
>   const char *path = getenv ("PATH");
>   if (!path)
>     path = CS_PATH;
> 
> and
> 
>       #define CS_PATH "/bin:/usr/bin"
> 
> This excludes the CWD from the list. And testing seems to
> confirm this.
> 
> I consider the change beneficial actually, since including 
> the CWD in the default search path does seem risky. 
> However, I see no mention in the commit message about this
> behavior change, nor could I see anything in NEWS. So, I
> wonder, was the change intended?

It seemed so obviously intentional at that time (it finally allowed ALT
to drop a local patch with the same effect) so I didn't manage
to point this out during review.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20171120/739414f1/attachment.sig>