execv on /proc/self/exe

[ratboy666]

When CEF3 (Chrome starts the GPU process, and possibly others), it does execv on /proc/self/exe, per below:

[pid 7712] execve("/proc/self/exe", ["/proc/self/exe", "--type=gpu-process", "-
-no-sandbox", "--log-file=/opt/exodus/bundles/1"..., "--log-severity=disable", "
--lang=en-US", "--gpu-preferences=KAAAAAAAAACAAA"..., "--log-file=/opt/exodus/bu
ndles/1"..., "--log-severity=disable", "--lang=en-US", "--service-request-channe
l-token="...], 0x7ffec1cf9ab0 /* 61 vars */) = 0

This does not work! At this time, /proc/self/exe refers to the original executable, and not the starter executable.

I am going to try: in the executable, iff the process name av[0] is /proc/self/exe, rerun with a modified loader, which, in turn will execv the executable with the correct environment. This is not a general solution -- that would probably require a preload of execv within the program starter.

I think that this is responsible for the problems I am having (trying to run a CEF3 based application on RHEL6).

Thanks in advance.
Fred Weigel

[sangaline]

Yeah, this is a real challenge. The reason that the linkers are placed in each directory where there's a launcher is so that programs which use /proc/self/exe to find the current directory can do so successfully. As you point out here, the full executable path belongs to the linker so this breaks applications that use this to launch child processes.

The solution that I've had in mind here for a while is to compile a small library that wraps readlink() and modifies the result of readlink("/proc/self/exe"). The library can then be preloaded by the launcher when invoking the linker. There are some things that make this a little tricky in practice, but it is something in the works.

If you run Chromium with --single-process, and possibly things like --disable-gpu-sandbox, does it make any difference? If Chromium weren't trying to invoke itself, I don't think this would be an issue.