Re: BUG: /proc/self/exe reports relative paths, should always return absolute paths?

[Svante Signell]

On Sat, 2017-09-09 at 22:04 +0200, Samuel Thibault wrote:
> Svante Signell, on sam. 09 sept. 2017 10:51:36 +0200, wrote:
> > On Fri, 2017-09-08 at 00:39 +0200, Samuel Thibault wrote:
> > > That goes back to file_exec_file_name provided with a relative path, and
> > > not
> > > an
> > > absolute path.  That's where it needs fixing.  I guess it could be a
> > > matter of making sysdeps/mach/hurd/execve.c call realpath(), as well as
> > > sysdeps/mach/hurd/spawni.c in the 
> > > if ((xflags & SPAWN_XFLAGS_USE_PATH) == 0 || strchr (file, '/') != NULL)
> > > case.
> > 
> > Sorry, but none of these changes had any effect. I built a new libc.so
> > including
> > print statements and run the programs with both LD_PRELOAD and
> > LD_LIBRARY_PATH.
> > No difference.
> 
> Which programs do you run?
> 
> execv/spawn are called from the parent, so the program that needs
> LD_LIBRARY_PATH is the parent of the program to be observed in
> /proc/pid/exe

Attached is a diff of the patch submitted-exec-filename.diff using realpath for
execve.c and spawni.c. The change of __execve fixes the /proc/self/exe problem.
What about freeing filename/file_name, using lstat instead of second argument of
realpath being NULL, declaring filename as const char* etc?

The second change of __spawni I did not find being effective. I added print
statements to all cases of the if then else construct, and nothing was printed
when running the test code with sh -c "..."

(some tab vs blank space differences might still be present)

submitted-exec_filename.diff.diff
Description: Text Data