Re: kern/58306: procfs does not remove dot segments from executable paths

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> From: matyalatte%gmail.com@localhost
> Date: Tue, 4 Jun 2024 15:00:00 +0000
> 
> It uses readlink("/proc/curproc/exe", path, PATH_MAX) to get an executable path on NetBSD.
> Then, I noticed the function does not remove dot segments when running the binary with a relative path like "./myexe."
> 
> I think the exe path should be normalized.

Why should the path be normalized like this?  Why can't you just use
realpath(3) on the result if you want it to be normalized?  Do other
kernels normalize it in procfs itself, and conceal the actual pathname
that was passed to execve?  Are there important applications that rely
on normalization?

The Linux man page doesn't say anything about normalization:

https://www.man7.org/linux/man-pages/man5/proc.5.html

       /proc/pid/exe
              Under Linux 2.2 and later, this file is a symbolic link
              containing the actual pathname of the executed command.
              This symbolic link can be dereferenced normally;
              attempting to open it will open the executable.  You can
              even type /proc/pid/exe to run another copy of the same
              executable that is being run by process pid.  If the
              pathname has been unlinked, the symbolic link will contain
              the string ' (deleted)' appended to the original pathname.
              In a multithreaded process, the contents of this symbolic
              link are not available if the main thread has already
              terminated (typically by calling pthread_exit(3)).

              Permission to dereference or read (readlink(2)) this
              symbolic link is governed by a ptrace access mode
              PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

              Under Linux 2.0 and earlier, /proc/pid/exe is a pointer to
              the binary which was executed, and appears as a symbolic
              link.  A readlink(2) call on this file under Linux 2.0
              returns a string in the format:

                  [device]:inode

              For example, [0301]:1502 would be inode 1502 on device
              major 03 (IDE, MFM, etc. drives) minor 01 (first partition
              on the first drive).

              find(1) with the -inum option can be used to locate the
              file.

The Linux kernel documentation on file systems, which may be more
authoritative, doesn't say anything about normalization either:

https://www.kernel.org/doc/html/latest/filesystems/api-summary.html#the-proc-filesystem

   Table 1-1: Process specific entries in /proc

   File         Content
   ...
   exe          Link to the executable of this process

Normalization, of course, can change over time, depending on directory
content and file system mounts.