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

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

The following reply was made to PR kern/58306; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: matyalatte%gmail.com@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58306: procfs does not remove dot segments from executable paths
Date: Tue, 4 Jun 2024 22:11:15 +0000

 > From: matyalatte%gmail.com@localhost
 > Date: Tue, 4 Jun 2024 15:00:00 +0000
 >=20
 > It uses readlink("/proc/curproc/exe", path, PATH_MAX) to get an executabl=
 e path on NetBSD.
 > Then, I noticed the function does not remove dot segments when running th=
 e binary with a relative path like "./myexe."
 >=20
 > 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-pro=
 c-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.