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

[Samuel Thibault]

Svante Signell, on jeu. 14 sept. 2017 14:10:05 +0200, wrote:
> With the updated patch things works fine:

Cool :)

> + __execve (const char *file_name, char *const argv[], char *const envp[])
> + {
> +   error_t err;
> +-  file_t file = __file_name_lookup (file_name, O_EXEC, 0);
> + 
> +-  if (file == MACH_PORT_NULL)
> ++  char *filename = realpath (file_name, NULL);
> ++  if (filename == NULL)
>       return -1;

Well, rather avoid having a 'filename' variable along the 'file_name'
variable, that's confusing :)

Better calling absolute_path for instance.

> ++  file_t file = __file_name_lookup (filename, O_EXEC, 0);

Why doing this?

[spawni]
> @@ -227,7 +273,7 @@
>   {
>     pid_t new_pid;
>     char *path, *p, *name;
> -+  const char *filename;
> ++  const char *filename, *file_name;

Same remark, all the more so since here it's even the converse naming...

> +@@ -545,8 +547,13 @@ __spawni (pid_t *pid, const char *file,
> +      etc) can be observed before what errors.  */
>   
>     if ((xflags & SPAWN_XFLAGS_USE_PATH) == 0 || strchr (file, '/') != NULL)
> -     /* The FILE parameter is actually a path.  */
> +-    /* The FILE parameter is actually a path.  */
>  -    err = child_lookup (file, O_EXEC, 0, &execfile);
> -+    err = child_lookup (filename = file, O_EXEC, 0, &execfile);
> ++    {
> ++      /* The FILE parameter is actually a path.  */
> ++      file_name = realpath (file, NULL);
> ++      if (file_name == NULL)
> ++    goto out;
> ++      err = child_lookup (filename = file_name, O_EXEC, 0, &execfile);

While you are at it, please move the = just before the child_lookup
call, as putting assignment within a function called would be frowned
upon.

And there is a missing free() for spawni. The easiest is probably to
initialize your absolute_path variable to NULL, and just always free it
in out:.

Samuel