Re: New sysctl entry: proc.PID.realpath

[Kamil Rytarowski <n54%gmx.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thank you for your insight!

On 07.09.2015 13:32, Robert Elz wrote:
> Date:        Mon, 07 Sep 2015 12:24:58 +0200 From:        Kamil 
> Rytarowski <n54%gmx.com@localhost> Message-ID:  <55ED65FA.1000702%gmx.com@localhost>
> 
> | I'm here to get the support for it. At the moment it (cache nits)
> | exceeds my comprehension too.
> 
> What is the semantic you're hoping to provide?   The path that was 
> used to exec the process, or the path that would be used now to
> get the same one?   [The difference is if the binary has been
> (re)moved between when it was exec'd and now.]
> 

The path that was used to execute the process. sysctl(7) can fail
gracefully and its collapse is easier to maintain (through the proper
interface) then almost undefined behavior of /proc/PID/exe.

> The exec time path is easier, and must exist (or the exec would 
> have failed), the current path is more useful, but not guaranteed 
> to exist, and much harder to find.
> 

I'm completely OK with possible failure if the file was moved or removed
.

I don't see need to scan the disk for its possible new location or
name. I prefer to receive failure then get it unexpectedly located
somewhere else.

> Which is wanted depends upon what the real purpose of this is - if 
> it is just to replace the entry in /proc then before doing that
> ask what use that has - does anything really use it, and if so,
> for what, and how well does it work.
> 

I started to search for its usage (readlink over /proc/PID/exe):
1. gdb
2. lldb
3. valgrind
4. Chromium
5. tup
6. GNUStep-base
7. Wireshark
8. Firefox
9. Openglad
10. Alcextra
11. Cafu
12. Caster
13. Physfs
14. jruby-launcher
15. CDE

And then I stopped as there was a set of over 100 more Open Source
projects. [1]

What's the use of /proc/PID/exe, for this please let me cite the
comment from CDE [2]:

      // super hack!  if the program is trying to access the special
      // /proc/self/exe file, return perceived_program_fullpath if
      // available, or else cde-exec will ERRONEOUSLY return the path
      // to the dynamic linker (e.g., ld-linux.so.2).
      //
      // programs like 'java' rely on the value of /proc/self/exe
      // being the true path to the executable, in order to dynamically
      // load libraries based on paths relative to that full path!
      char is_proc_self_exe = (strcmp(filename, "/proc/self/exe") == 0);

      // another super hack!  programs like Google Earth
      // ('googleearth-bin') access /proc/self/exe as /proc/<pid>/exe
      // where <pid> is ITS OWN PID!  be sure to handle that case proper
ly
      // (but don't worry about handling cases where <pid> is the PID of
      // another process).
      //
      // (again, these programs use the real path of /proc/<pid>/exe as
      // a basis for dynamically loading libraries, so we must properly
      // 'fake' this value)
      char* self_pid_name = format("/proc/%d/exe", tcp->pid);

> Others have been suggesting that the use is for debuggers (gdb or 
> whatever). If that's it, and the only reason, then personally I'd 
> just forget it. If someone is debugging a process, but can't even 
> work out where the binary is (or is too lazy to type it) then I'd 
> suggest that they ought to just give up...
> 
> On the other hand, if it is so the debugger can verify that it is
working
> from the correct binary file, then the pathname isn't needed, just 
> the <dev, ino> pair, which is the true name of a unix file 
> (pathnames are just a human interface improvement ... and a bit of 
> added security). With just that, the debugger can verify that the 
> file running
(assuming that
> sysctl (or /proc) provide that info) is the one that the user told
them is
> to be debugged, and issue a warning (or whatever) if the don't 
> match.
> 
> Alternatively, perhaps there's some other use ?
> 
> kre
> 

This sysctl(7) happened to be handy for libproc, as a missing puzzle
for our userland DTrace support. I don't want to focus on every
legitimate usage, as there set of software using it is very wide; I
would focus now on rather providing the software -- in my case lldb(1)
- -- what it expects and let it process further.

To sum it up, the overview gave me the idea that proc.PID.realpath:
- - must be absolute path,
- - preferably canonicalized (links, '.' and '..' resolved) - if so then
call it .realpath, if not then .pathname (to be compatible with FreeBSD)
,
- - pathname of the execution time,
- - missing, moved, removed or replaced file - let the consumer of this
interface handle it on his or her own.

There are in-kernel issues with long path names, as we store limited
number of characters. I would leave this as it is, as the current
limits handle sane number of characters (PATH_MAX is 1024 [3]) for
most normal use-cases.

Both narrow cases (alteration to the executable) and pathname limits
should never happed in a properly designed software and environment.

Why to add another interface for the same thing?
- - safety (hide pathname from unprivileged users),
- - stop depending upon hard-coded path of procfs and its existance,
- - easier error handling through C-language level interface.

My personal use-case is to have full-featured lldb(1) in a procfs-less
system. This includes standard usage, not walk-arounding
environment problems.

[1] According to https://searchcode.com
[2] https://searchcode.com/codesearch/view/96415437/#l-1072
[3] src/sys/sys/syslimits.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV94lzAAoJEEuzCOmwLnZsu+8P/iusHPrqZsEzJ5/qmAuc51+3
VcZM3nptpGFJ9g/gg25LuSj21I1+b+NyIEbpLsTYYcXbfaWfbRD4LlYoRLwP9kLa
yPfMiDWOJ5DWRigF674AZiRIC/TUzB4ECCVNfHe8twXcpGMIyiqtJITAKwfSBXeV
RpBUc8HusDohRZybEJbJjwLH7GIugvUnoPLoBTB/QTMjs9orjuIu0EU7oDAAZnxY
tCkxH43fXmfmoL+UPavoIh7nD0Z6avPCk29cKodnrMEIR0m7CgtvVPdo/cdrgy6p
/yEndy555KtmG3oFO3qeXsrKiquylpzSx2K1fl921n5bgOGxSoVhkMmJ5RxQfkuV
GbbFU8efoDe4s8QnGm+p93nUIq+OQZMNc5M75mkIu2VkU4BcBcCdBywXoQCAvTh7
MMXQ8e7xddw/ZgG9MaadqS+hwEnrfgMBFsjlbC2LyL8QWYjNai7GSy++ETjx28vY
Tzvi6fT2jQTCHaKl+8mKAR3oRlTSUL/omqSbtkb5D0doq2olWxU3l4aPECz69Mmm
VteBBJfKSdyWPcWAD4fGCbh0QiPDwCZGp7fsuaAfgfUqhyEEWWs/8H+4cOFYf2Ir
RIzWn7equf0cTkHu/5Sq+sm0W1M77xL6i2AksE2i5uG18Wcv0p02lfgU/yvtLRUa
tVJqJp751FBn1qnvngDd
=Sqjh
-----END PGP SIGNATURE-----